Clearing global statistics
in [PgSql]
|
From: Greg Smith on 12 Jan 2010 13:46 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? -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Euler Taveira de Oliveira on 12 Jan 2010 20:29 Greg Smith escreveu: > pg_stat_reset( which text ) > which := 'buffers' | 'checkpoints' | 'tables' | 'functions' | ... > What about adding 'all' too? Or the idea is resetting all global counters when we call pg_stat_reset() (without parameters)? -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 14 Jan 2010 05:12 2010/1/12 Greg Smith <greg(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Rafael Martinez on 14 Jan 2010 08:42 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Smith wrote: > 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. >> [.........] > > Any comments before I update my patch to do that? > Hello 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) Statistics without time period information are unfortunately not very usefull for a DBA :-( 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. I tried to discuss this some time ago but we did not get anywhere, Ref: http://archives.postgresql.org/pgsql-general/2009-07/msg00614.php Maybe this time? :-) Is there any chance of implementing a way of knowing when was the last time statistics delivered via pg_stat_* were reset? regards, - -- Rafael Martinez, <r.m.guerrero(a)usit.uio.no> Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQFLTx9cBhuKQurGihQRAnTZAJ9afYGu4UShAha0L6Z3OFyqgJ6SJQCffEow sfFKKoT3ODap6JRpn2I1IfI= =bCqY -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Jan 2010 11:01 Rafael Martinez <r.m.guerrero(a)usit.uio.no> writes: > Is there any chance of implementing a way of knowing when was the last > time statistics delivered via pg_stat_* were reset? Actually, that brings up a more general question: what's with the enthusiasm for clearing statistics *at all*? ISTM that's something you should do only in dire emergencies, like the collector went haywire and has now got a bunch of garbage numbers. The notion of resetting subsets of the stats seems even more dubious, because now you have numbers that aren't mutually comparable. So I fail to understand why the desire to expend valuable development time on any of this. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 Prev: Fix for memory leak in dblink Next: [HACKERS] Any ExecStoreTuple end runs? |