Re: Clearing global statistics

Magnus Hagander wrote:
> I have on my TODO to implement the ability to do stats reset on a
> single object (say, one table only). Please take this into
> consideration when you design/name this, so theres no unnecessary
> overlap :-) Same goes for the stats message itself.
>   

The idea suggested upthread was to add this:

pg_stat_reset( which text )      which := 'buffers' | 'checkpoints' | 'tables' | 'functions' |  ...

Now, the way the pg_stat_bgwriter tables are computed, it doesn't 
actually make sense to separate out clearing the buffers/checkpoints 
stats, since one of those values is in both categories:  
buffers_checkpoint.  They're really all too tightly coupled to break 
them apart.  So I was thinking of this:

pg_stat_reset( which text )      which := 'bgwriter' | ...

I could convert the patch I've got to be an initial implementation of 
this new "pg_stat_reset with a parameter", laying some useful groundwork 
in the process too.  Then people who want to reset more things can just 
re-use that same outline and message passing mechanism, just adding 
comparisons for new text and a handler to go with it--not even touching 
the catalog again.

This may not mesh well with what you plan though.  If pg_stat_reset is 
updated to reset stats on an individual table, that could be a second 
version that takes in a regclass:

pg_stat_reset('tablename'::regclass)

But that seems like a confusing bit of overloading--I can easily see 
people thinking that pg_stat_reset('bgwriter') would be resetting the 
stats for a relation named 'bgwriter' rather than what it actually does 
if I build it that way.

So, combining with Peter's naming suggestion, I think what I should 
build is:

pg_stat_reset_shared( which text )      which := 'bgwriter' | ...

Which satisfies what I'm looking for now, and future patches that need 
to reset other shared across the cluster statistics can re-use this 
without needing to add a whole new function/stats message.  I think that 
satisfies the cross-section of planned use cases we're expecting now best.

Any comments before I update my patch to do that?

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