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 [EMAIL PROTECTED] 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?" ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
