Re: Acclerating INSERT/UPDATE using UPS

From: August Zajonc <augustz(at)augustz(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Acclerating INSERT/UPDATE using UPS
Date: 2007-03-09 07:44:46
Message-ID: 45F1106E.5080900@augustz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joshua D. Drake wrote:
> From an deployable application perspective, this could be a big deal. We
> are already starting to see very large traction in the Win32 desktop app
> arena.
>

There seem to be a few overlapping proposals in terms of reducing
various guarantees in the name of performance.

As more and more options are added that affect integrity (fsync, full
page writes, commit nowait, sigres) it might be nice to outline and
compare the approaches, and particularly to describe clearly the failure
scenarios and how they are significantly different from one another.

One potentially needs to track an increasing number of ways in which
items might be set which reduce certain guarantees on data integrity
which is unpleasant.

If a setting is wrong on a performance knob, no problem, when there are
complaints things are slow you can go through and adjust them. The same
is not true of data consistency. When the complaint comes it is usually
too late to fiddle with knobs.

I'm just thinking some caution should be exercised in adding too many of
them in the first place. I happen to love COMMIT NOWAIT though, for
many, this replaces fsync=off.

- August

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2007-03-09 08:16:12 Re: pgsql: Remove unsafe calling of WSAStartup and WSA Cleanup from DllMain.
Previous Message ITAGAKI Takahiro 2007-03-09 07:08:59 Re: Log levels for checkpoint/bgwriter monitoring