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

Re: Clearing global statistics

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Rafael Martinez <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clearing global statistics
Date: 2010-01-14 17:54:20
Message-ID: 4B4F5A4C.5000802@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Rafael Martinez wrote:
> One thing I miss from the statistics you can get via pg_stat_* is
> information about how long we have been collecting stats (or in other
> words, when was the last time the stats were reset)
>   

I've considered adding this for the same reasons you're asking about it, 
but am not happy with the trade-offs involved.  The problem is that you 
have to presume the server was running the entirety of the time since 
stats were reset for that data to be useful.  So unless people are in 
that situation, they're going to get data that may not represent what 
they think it does.  Realistically, if you want a timestamp that always 
means something useful you have to rest the stats at every server start, 
which leads us to:

> Before 8.3, we had the stats_reset_on_server_start parameter and the
> pg_postmaster_start_time() function. This was an easy way of resetting
> *all* statistics delivered by pg_stat_* and knowing when this was done.
> We were able to produce stats with information about sec/hours/days
> average values in an easy way.
>   

With this new feature I'm submitting, you can adjust your database 
startup scripts to make this happen again.  Start the server, 
immediately loop over every database and call pg_stat_reset on them all, 
and call pg_stat_reset_shared('bgwriter').  Now you've got completely 
cleared stats that are within a second or two of 
pg_postmaster_start_time(), should be close enough to most purposes.  
Theoretically we could automate that better, but I've found it hard to 
justify working on given that it's not that difficult to handle outside 
of the database once the individual pieces are exposed.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com  www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2010-01-14 18:00:06
Subject: Re: archive_timeout behavior for no activity
Previous:From: Tim BunceDate: 2010-01-14 17:49:54
Subject: Re: Miscellaneous changes to plperl [PATCH]

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