Re: CommitDelay performance improvement

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Myers 2001-02-23 22:57:36 Re: CommitDelay performance improvement
Previous Message Tom Lane 2001-02-23 22:33:56 Re: CommitDelay performance improvement