On Thu, Jan 14, 2010 at 1:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote:
>>> Actually, that brings up a more general question: what's with the
>>> enthusiasm for clearing statistics *at all*?
>> ... 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.
> 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.
True, but it's also more complicated to use. Most systems I'm
familiar with that have performance counters just provide an option
to clear them. Despite the disadvantages you cite, it seems to be
fairly useful in practice; anyway, I have found it so.
 The other design I've seen is a system that automatically resets,
say, once a day. It retains the statistics for the 24-hour period
between the most recent two resets, and the statistics for the partial
period following the last reset. But that doesn't seem appropriate
In response to
pgsql-hackers by date
|Next:||From: Hitoshi Harada||Date: 2010-01-17 06:28:45|
|Subject: Re: review: More frame options in window functions|
|Previous:||From: Josh Berkus||Date: 2010-01-16 23:53:54|
|Subject: Re: Streaming replication status|