On Thu, 12 Jul 2007, Gregory Stark wrote:
In any case I wouldn't think the use case for a feature like this would actually apply in the case of a benchmark.
I've also seen a tiny setting for commit_delay (like the 10 they used) as helping improve throughput under a heavy commit load with many processors. I'm not sure why a quick yield of the processor at that point helps, but there seem to be cases where it does. Don't think it has anything to do with the originally intended use for this parameter, probably some sort of OS scheduler quirk.
The use case where something like this is needed is where there are not enough concurrent requests to keep the server busy during the fsync of the wal.
I've actually finished an long investigation of this recently that will be on my web page soon. On a non-caching controller where you'd think there's the most benefit here, I was only able to get about 10% more commits at low client loads by setting the delay to about 1/2 of the fsync time, and a few percent more at high loads by setting a delay longer than the fsync time. It's really a slippery setting though--very easy to set in a way that will degrade performance significantly if you're not very systematic about testing it many times at various client counts.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
