On Fri, Feb 23, 2001 at 05:18:19PM -0500, Tom Lane wrote:
> ncm@zembu.com (Nathan Myers) writes:
> >> Comments? What should the threshold N be ... or do we need to make
> >> that a tunable parameter?
>
> > Once you make it tuneable, you're stuck with it. You can always add
> > a knob later, after somebody discovers a real need.
>
> If we had a good idea what the default level should be, I'd be willing
> to go without a knob. I'm thinking of a default of about 5 (ie, at
> least 5 other active backends to trigger a commit delay) ... but I'm not
> so confident of that that I think it needn't be tunable. It's really
> dependent on your average and peak transaction lengths, and that's
> going to vary across installations, so unless we want to try to make it
> self-adjusting, a knob seems like a good idea.
>
> A self-adjusting delay might well be a great idea, BTW, but I'm trying
> to be conservative about how much complexity we should add right now.
When thinking about tuning N, I like to consider what are the interesting
possible values for N:
0: Ignore any other potential committers. 1: The minimum possible responsiveness to other committers. 5: Tom's guess
forwhat might be a good choice. 10: Harry's guess. ~0: Always delay.
I would rather release with N=1 than with 0, because it actually responds
to conditions. What N might best be, >1, probably varies on a lot of
hard-to-guess parameters.
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.
Nathan Myers
ncm@zembu.com
