On Sat, 8 Sep 2007, Tom Lane wrote:
I've already gotten flak about the current default of 200ms:
I can't imagine that folk with those types of goals will tolerate an
un-tunable 10ms cycle.
That's the counter-example for why lowering the default is unacceptable I
was looking for. Scratch bgwriter_delay off the list of things that might
be fixed to a specific value.
Will return to the drawing board to figure out a way to incorporate what
I've learned about running at 10ms into a tuning plan that still works
fine at 200ms or higher. The good news as far as I'm concerned is that I
haven't had to adjust the code so far, just tweak the existing knobs.
In fact, given the numbers you show here, I'd say you should leave the
default cycle time at 200ms. The 10ms value is eating way more CPU and
producing absolutely no measured benefit relative to 200ms...
My server is a bit underpowered to run at 10ms and gain anything when
doing a stress test like this; I was content that it didn't degrade
performance significantly, that was the best I could hope for. I would
expect the class of systems that Simon and Heikki are working with could
show significant benefit from running the BGW that often.
* 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