Re: CommitDelay performance improvement

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