Thread: Re: [PATCHES] COMMIT NOWAIT Performance Option (patch)

Re: [PATCHES] COMMIT NOWAIT Performance Option (patch)

From
"Simon Riggs"
Date:
On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > A prototype patch is posted to -patches, which is WORK IN PROGRESS.
> > [This patch matches discussion thread on -hackers.]
>
> What does this accomplish other than adding syntactic sugar over a
> feature that really doesn't work well anyway?  I don't see any point
> in encouraging people to use commit_delay in its present form.  If we
> had a portable solution for millisecond-or-so waits then maybe it would
> work ...

This patch doesn't intend to implement group commit. I've changed the
meaning of commit_delay, sorry if that confuses.

You and I discussed this in Toronto actually, IIRC. The best way to
describe this proposal is deferred fsync, so perhaps a different
parameter commit_fsync_delay would be more appropriate.

Bruce has requested this feature many times from me, so I thought it
about time to publish.

The key point is that COMMIT NOWAIT doesn't wait for group commit to
return, it just doesn't wait at all - leaving someone else to flush WAL.
It's much better than fsync=off.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



Re: [PATCHES] COMMIT NOWAIT Performance Option (patch)

From
Tom Lane
Date:
"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Mon, 2007-02-26 at 18:14 -0500, Tom Lane wrote:
>> What does this accomplish other than adding syntactic sugar over a
>> feature that really doesn't work well anyway?

> This patch doesn't intend to implement group commit. I've changed the
> meaning of commit_delay, sorry if that confuses.

Ah.  The patch was pretty much unintelligible without the discussion
(which got here considerably later :-().  I've still got misgivings
about how safe it really is, but at least this is better than what
commit_delay wishes it could do.

            regards, tom lane