Re: Autotuning Group Commit

On Sat, Jan 22, 2005 at 08:47:37AM +0000, Simon Riggs wrote:
> On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
> > 1) I'm in favor of autotuning anything possible.
> > 2) In addition to turning group_commit on and off, what about also
> > adjusting the commit delay, based on statistics of recent commits? It
> > might require a slightly larger sample set (maybe the last 100 commits),
> > but it seems it would provide more flexibility (hence more usefulness)
> > to the autotuning.
> > 
> > I belive you'd want to first calculate the elapsed time between each
> > commit in the sample set, then look for groupings of elapsed time. If
> > you have a set that looks like this:
> > 
> > Time (ms)  Number
> > 2   *
> > 4   *
> > 6   
> > 8   **
> > 10  *
> > 12  ******
> > 14  ****
> > 16  **
> > 18  
> > 20  *
> > 
> > then you'd want a delay of 16ms. I think this calculation could be done
> > fairly quickly by grouping the commits into buckets of different elapsed
> > times, then look for the largest elapsed time that has a number of
> > commits greater than the mean number of commits for all the buckets. But
> > I'm not a statistician, hopefully someone here is. :)
> 
> Yes, I considered that, but since we're talking about a frequently
> executed piece of code, I was hoping to keep it short and sweet.
> What do others think?
I don't think the frequently executed code would need to differ between
the two options. The remaining analysis would be done by a background
process.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"