Re: CommitDelay performance improvement

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: CommitDelay performance improvement
Дата
Msg-id 200102232238.RAA02964@candle.pha.pa.us
обсуждение исходный текст
Ответ на CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Commit delay (was Re: beta5 packages)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CommitDelay performance improvement