2010/1/12 Greg Smith <g...@2ndquadrant.com>:
> Magnus Hagander wrote:
>>
>> I have on my TODO to implement the ability to do stats reset on a
>> single object (say, one table only). Please take this into
>> consideration when you design/name this, so theres no unnecessary
>> overlap :-) Same goes for the stats message itself.
>>
>
> The idea suggested upthread was to add this:
>
> pg_stat_reset( which text )
> which := 'buffers' | 'checkpoints' | 'tables' | 'functions' | ...
>
> Now, the way the pg_stat_bgwriter tables are computed, it doesn't actually
> make sense to separate out clearing the buffers/checkpoints stats, since one
> of those values is in both categories: buffers_checkpoint. They're really
> all too tightly coupled to break them apart. So I was thinking of this:
>
> pg_stat_reset( which text )
> which := 'bgwriter' | ...
>
> I could convert the patch I've got to be an initial implementation of this
> new "pg_stat_reset with a parameter", laying some useful groundwork in the
> process too. Then people who want to reset more things can just re-use that
> same outline and message passing mechanism, just adding comparisons for new
> text and a handler to go with it--not even touching the catalog again.
>
> This may not mesh well with what you plan though. If pg_stat_reset is
> updated to reset stats on an individual table, that could be a second version
> that takes in a regclass:
>
> pg_stat_reset('tablename'::regclass)
>
> But that seems like a confusing bit of overloading--I can easily see people
> thinking that pg_stat_reset('bgwriter') would be resetting the stats for a
> relation named 'bgwriter' rather than what it actually does if I build it
> that way.
>
> So, combining with Peter's naming suggestion, I think what I should build is:
>
> pg_stat_reset_shared( which text )
> which := 'bgwriter' | ...
>
> Which satisfies what I'm looking for now, and future patches that need to
> reset other shared across the cluster statistics can re-use this without
> needing to add a whole new function/stats message. I think that satisfies
> the cross-section of planned use cases we're expecting now best.
>
> Any comments before I update my patch to do that?
Are you planning to get this in for the CF? (Yes, I realize there are
only hours left). This is functionality I'd *really* like to see in
8.5, so I'll be happy to work with you to get that committed inside or
outside CF bounds, but it's easier if it's on there for reviewers ;)
(plus, the "outside cf bounds" really only works *before* the
commitfest :P)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
