On Fri, 9 Mar 2007, Tom Lane wrote:
I'd be interested to know what scale factor and shared_buffers setting led to the above measurement.
That was just a trivial example with 1 client, scale=10 (~160MB database), and shared_buffers=24MB. Where things really get interesting with pgbench is on a system with enough horsepower+clients to dirty the whole buffer cache well before a checkpoint. I regularly see >75% of the cache dirty and blocked from LRU writes with pgbench's slightly pathological workload in that situation.
You're correct that these results aren't particularly surprising or indicative of a problem to be corrected. But they do shed some light on what pgbench is and isn't appropriate for testing.
It strikes me that the patch would be more useful if it produced a histogram of the observed usage_counts, rather than merely the count for usage_count = 0.
I'll start working in that direction. With the feedback everyone has given me on how few of the buffers are truly "pinned" via the correct usage of the term, I'm going to revisit the usage details and revise that section. I'm happy with how I'm reporting the checkpoint details now, still some work left to do on the bgwriter activity.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
