Re: CommitDelay performance improvement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommitDelay performance improvement
Date: 2001-02-23 22:33:56
Message-ID: 982.982967636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-02-23 22:38:48 Re: CommitDelay performance improvement
Previous Message Bruce Momjian 2001-02-23 22:26:53 Re: CommitDelay performance improvement