Re: CommitDelay performance improvement

Поиск
Список
Период
Сортировка
От ncm@zembu.com (Nathan Myers)
Тема Re: CommitDelay performance improvement
Дата
Msg-id 20010223202440.A19527@store.zembu.com
обсуждение исходный текст
Ответ на Re: CommitDelay performance improvement  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Feb 23, 2001 at 09:05:20PM -0500, Bruce Momjian wrote:
> > > > It seems to me that comparing various choices (and other, more
> > > > interesting, algorithms) to the N=1 case would be more productive
> > > > than comparing them to the N=0 case, so releasing at N=1 would yield
> > > > better statistics for actually tuning in 7.2.
> > >
> > > We don't release code because it has better tuning opportunities for
> > > later releases. What we can do is give people parameters where the
> > > default is safe, and they can play and report to us.
> > 
> > Perhaps I misunderstood.  I had perceived N=1 as a conservative choice
> > that was nevertheless preferable to N=0.
> 
> I think zero delay is the conservative choice at this point, unless we
> hear otherwise from testers.

I see, I had it backwards: N=0 corresponds to "always delay", and 
N=infinity (~0) is "never delay", or what you call zero delay.  N=1 is 
not interesting.  N=M/2 or N=sqrt(M) or N=log(M) might be interesting, 
where M is the number of backends, or the number of backends with begun 
transactions, or something.  N=10 would be conservative (and maybe 
pointless) just because it would hardly ever trigger a delay.

Nathan Myers
ncm@zembu.com


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

Предыдущее
От: "Rainer Mager"
Дата:
Сообщение: RE: [BUGS] Problem with 7.0.3 dump -> 7.1b4 restore
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: CommitDelay performance improvement