Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CommitDelay performance improvement
Date
Msg-id 982.982967636@sss.pgh.pa.us
Whole thread Raw
In response to Re: CommitDelay performance improvement  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> A self-adjusting delay might well be a great idea, BTW, but I'm trying
>> to be conservative about how much complexity we should add right now.

> OH, so you are saying N backends should have dirtied buffers before
> doing the delay?  Hmm, that seems almost untunable to me.

> Let's suppose we decide to sleep.  When we wake up, can we know that
> someone else has fsync'ed for us?

XLogFlush will find that it has nothing to do, so yes we can.

> And if they have, should we be more
> likely to fsync() in the future?

You mean less likely.  My thought for a self-adjusting delay was to
ratchet the delay up a little every time it succeeds in avoiding an
fsync, and down a little every time it fails to do so.  No change when
we don't delay at all (because of no other active backends).  But
testing this and making sure it behaves reasonably seems like more work
than we should try to accomplish before 7.1.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: CommitDelay performance improvement
Next
From: Tom Lane
Date:
Subject: Re: CommitDelay performance improvement