2010/1/12 Greg Smith <greg@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/checkpointsstats, since one of those values is in both categories: buffers_checkpoint. They're really all too
tightlycoupled 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",
layingsome useful groundwork in the process too. Then people who want to reset more things can just re-use that same
outlineand message passing mechanism, just adding comparisons for new text and a handler to go with it--not even
touchingthe 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,
thatcould 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')
wouldbe 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
statisticscan re-use this without needing to add a whole new function/stats message. I think that satisfies the
cross-sectionof 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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
