Re: Clearing global statistics

Tom Lane wrote:
> Actually, that brings up a more general question: what's with the
> enthusiasm for clearing statistics *at all*?  ISTM that's something
> you should do only in dire emergencies, like the collector went
> haywire and has now got a bunch of garbage numbers.  The notion of
> resetting subsets of the stats seems even more dubious, because now
> you have numbers that aren't mutually comparable.  So I fail to
> understand why the desire to expend valuable development time on
> any of this.
>   

When doing checkpoint tuning, the usual thing you start with is by 
considering the ratio of time to segment-based checkpoints, along with 
the corresponding balance of buffers written by the backends vs. the 
checkpoint.  When that shows poor behavior, typically because 
checkpoint_segments is too low, you change its value and then resume 
monitoring at the new setting.  Right now, you're still carrying around 
the history of the bad period forever though, and every check of the 
pg_stat_bgwriter requires manually subtracting the earlier values out.  
What people would like to do is reset those after adjusting 
checkpoint_segments, and then you can eyeball the proportions directly 
instead.  That's exactly what the patch does.  If I didn't see this 
request in the field every month I wouldn't have spent a minute on a 
patch to add it.

There was a suggestion that subsets of the data I'm clearing might be 
useful to target, which I rejected on the bounds that it made it 
possible to get an inconsistent set of results as you're concerned 
about.  You really need to clear everything that shows up in 
pg_stat_bgwriter or not touch it at all.  The main use case I'm trying 
to support is the person who just made a config change and now wants to do:

select pg_stat_reset();
select pg_stat_reset_shared('bgwriter');

So that all of the stats they're now dealing with are from the same 
post-tuning time period.  Having numbers that are "mutually comparable" 
across the whole system is exactly the reason why this new call is 
needed, because there's this one part you just can't touch.

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