I had such great hopes for this thread. "Alas, poor Yorick! I
knew him, Horatio ..."
On Thu, Jul 12, 2007 at 11:00:54AM -0400, Greg Smith wrote:
> 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
>
> ---------------------------(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
