Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: CommitDelay performance improvement
Date
Msg-id 200102232238.RAA02964@candle.pha.pa.us
Whole thread Raw
In response to CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > And if they have, should we be more
> > likely to fsync() in the future?

I meant more likely to sleep().

> 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.

It could be tough.  Imagine the delay increasing to 3 seconds?  Seems
there has to be an upper bound on the sleep.  The more you delay, the
more likely you will be to find someone to fsync you.  Are we waking
processes up after we have fsync()'ed them?  If so, we can keep
increasing the delay.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Commit delay (was Re: beta5 packages)
Next
From: Tom Lane
Date:
Subject: Re: CommitDelay performance improvement