Re: CommitDelay performance improvement

> > 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026