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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
