Advertising

uint16 usage_count; /* usage counter for clock sweep code */

and you have a int16 to store that. Currently the max buffer count is
5. But is that a complete safe assumption? Maybe a compile time check
that BM_MAX_USAGE_COUNT is < 16k would ensure that things don't go wrong?

Regards
Russell Smith
Greg Smith wrote:

This patch adds the usage count statistic to the information available
in contrib/pgbuffercache. Earlier this month a discussion about my
first attempt to instrument the background writer had Tom asking for
details about the usage histogram I was seeing, and this patch proved
to be the easiest way I found to take a look at that.

In situations where one is trying to optimize the background writer,
it's very hard to adjust how much to rely on the LRU writer versus the
one that writes everything unless you know whether your dirty buffers
are typically used heavily (like index blocks) or not (like new INSERT
data). Some statistics about the usage counts in your buffer cache
are extremely helpful in making that decision.

I'll even pass along an ugly but fun query that utilizes this. The
following will give you a summary of your buffer cache broken into 32
sections. Each line shows the average usage count of that section, as
a positive number if most buffers dirty and a negative one if most are
clean. If you refresh this frequently enough, you can actually watch
things like how checkpoints move through the buffer cache:

The 32 can be changed to anything, that's just what fits on my screen.
The main idea of the above is that if you dump all this to a file
regularly, it's possible to produce a graph of it showing how the
cache has changed over time by assigning a different color intensity
based on the usage count--at a massive cost in overhead, of course.
I'll be passing along all that code once I get it ready for other
people to use.