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

Re: Clearing global statistics

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Clearing global statistics
Date: 2010-01-14 21:20:22
Message-ID: 4B4F8A96.5080004@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Itagaki Takahiro wrote:
> To be honest, I have a plan to add performance statistics counters to
> postgres. It is not bgwriter's counters, but cluster-level. I'd like
> to use your infrastructure in my work, too :)
>   

Attached patch provides just that. It still works basically the same as 
my earlier version, except you pass it a name of what you want to reset, 
and if you don't give it the only valid one right now ('bgwriter') it 
rejects it (for now):

gsmith=# select checkpoints_req,buffers_alloc from pg_stat_bgwriter;
checkpoints_req | buffers_alloc
-----------------+---------------
4 | 129
(1 row)

gsmith=# select pg_stat_reset_shared('bgwriter');
pg_stat_reset_shared
----------------------

(1 row)

gsmith=# select checkpoints_req,buffers_alloc from pg_stat_bgwriter;
checkpoints_req | buffers_alloc
-----------------+---------------
0 | 7
(1 row)

gsmith=# select pg_stat_reset_shared('rubbish');
ERROR: Unrecognized reset target

I turn the input text into an enum choice as part of composing the 
message to the stats collector. If you wanted to add some other shared 
cluster-wide reset capabilities into there you could re-use most of this 
infrastructure. Just add an extra enum value, map the text into that 
enum, and write the actual handler that does the reset work. Should be 
able to reuse the same new message type and external UI I implemented 
for this specific clearing feature.

I didn't see any interaction to be concerned about here with Magnus's 
suggestion he wanted to target stats reset on objects such as a single 
table at some point.

The main coding choice I wasn't really sure about is how I flag the 
error case where you pass bad in. I do that validation and throw 
ERRCODE_SYNTAX_ERROR before composing the message to the stats 
collector. Didn't know if I should create a whole new error code just 
for this specific case or if reusing another error code was more 
appropriate. Also, I didn't actually have the collector process itself 
validate the data at all, it just quietly ignores bad messages on the 
presumption everything is already being checked during message creation. 
That seems consistent with the other code here--the other message 
handlers only seem to throw errors when something really terrible 
happens, not when they just don't find something useful to do.

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


Attachment: stat-reset-global-v3.patch
Description: text/x-patch (7.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Alex HunsakerDate: 2010-01-14 21:24:16
Subject: Re: Source code for pg_bulkload
Previous:From: Dann CorbitDate: 2010-01-14 21:13:10
Subject: Source code for pg_bulkload

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