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
Re: CommitDelay performance improvement |
Список | 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 по дате отправления: