Re: CommitDelay performance improvement

On Fri, Feb 23, 2001 at 05:18:19PM -0500, Tom Lane wrote:
> ncm(at)zembu(dot)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 for what 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(at)zembu(dot)com