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 [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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
