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