From: | ncm(at)zembu(dot)com (Nathan Myers) |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CommitDelay performance improvement |
Date: | 2001-02-24 04:24:40 |
Message-ID: | 20010223202440.A19527@store.zembu.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)zembu(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2001-02-24 04:26:14 | Re: CommitDelay performance improvement |
Previous Message | Bruce Momjian | 2001-02-24 04:14:21 | Re: CommitDelay performance improvement |