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. :) -- 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
