Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group