Skip site navigation (1) Skip section navigation (2)

Re: Clearing global statistics

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clearing global statistics
Date: 2010-01-14 18:46:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Seems like a more appropriate solution would be to make it easier to do
> that subtraction, ie, make it easier to capture the values at a given
> time point and then get deltas from there.  It's more general (you could
> have multiple saved sets of values), and doesn't require superuser
> permissions to do, and doesn't have the same potential for
> damn-I-wish-I-hadn't-done-that moments.

You can make the same argument about the existing pg_stat_reset 
mechanism.  I would love to completely rework the stats infrastructure 
so that it's easier to capture values with timestamps, compute diffs, 
and do trending.  However, I'm not sure the database itself is 
necessarily the best place to do that at anyway.  People who know what 
they're doing are already handling this exact job using external tools 
that grab regular snapshots for that purpose, so why try to duplicate 
that work?

I'm trying to triage here, to scrub off the worst of the common 
problems.  I would never claim this is the perfect direction to follow 
forever.  There are a number of people who consider the inability to 
reset the pg_stat_bgwriter stats in any way a bug that's gone unfixed 
for two versions now.  Your larger point that this style of 
implementation is not ideal as a long-term way to manage statistics I 
would completely agree with, I just don't have the time to spend on a 
major rewrite to improve that.  What I can offer is a fix for the most 
common issue I get complaints about, in the form of a tool much more 
likely to be used correctly by people who go looking for it than misused 

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: David FetterDate: 2010-01-14 18:55:16
Subject: Re: Miscellaneous changes to plperl [PATCH]
Previous:From: Pavel StehuleDate: 2010-01-14 18:40:32
Subject: Re: EXPLAIN, utility statement parameters, and recent plpgsql changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group