Clearing global statistics

Since the pg_stat_bgwriter structure was introduced in 8.3, there's 
never been any way to reset its statistics back to 0.  A week of 
analyzing data from that every day drove me crazy enough to finally fix 
this with the attached patch.  This implements the TODO item "Allow the 
clearing of cluster-level statistics", based on previous discussion 
ending at http://archives.postgresql.org/pgsql-hackers/2009-03/msg00920.php

Here's the patch in action:

gsmith=# select checkpoints_req,buffers_alloc from pg_stat_bgwriter;
 checkpoints_req | buffers_alloc
-----------------+---------------
               1 |             5

gsmith=# select pg_stat_reset_global();

gsmith=# select checkpoints_req,buffers_alloc from pg_stat_bgwriter;
 checkpoints_req | buffers_alloc
-----------------+---------------
               0 |             0

Patch is complete including docs, it's basically just pg_stat_reset with 
a different clearing mechanism at the very end.  My list of potential 
questions here are:

-Not sure if this should be named pg_stat_rest_global (to match the way 
these are called "global stats" in the source) or 
pg_stat_reset_cluster.  Picked the former for V1, not attached to that 
decision at all.  Might even make sense to use a name that makes it 
obvious the pg_stat_bgwriter data is what's targeted.

-I create a new stats message type for this, but just reuse the same 
message payload structure as pg_stats_reset rather than add a new 
payload structure for no good reason.  That's marked with two XXX s in 
the code as a questionable design decision.  I can implement that too if 
there's some reason it's a good idea I don't know yet.

-I grabbed what looked like an appropriate unused OID.  I'm never sure 
if I did that right or not though, it may need to be renumbered.

Since this whole patch is basically a cut and paste job of code that was 
already there, I don't really expect it to need much discussion beyond 
these minor points; wouldn't have sent it in the middle of an active 
CommitFest if that weren't the case.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com