Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Haribabu Kommi <kommi.haribabu@gmail.com>
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Magnus Hagander <magnus@hagander.net>, sk@zsrv.org, Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Euler Taveira <euler@timbira.com.br>,
Pg Hackers <pgsql-hackers@postgresql.org>, Simon Riggs <simon@2ndquadrant.com>, Dave Page <dpage@pgadmin.org>
Date: 2018-11-18T23:41:22Z
Lists: pgsql-hackers
On Sun, Nov 18, 2018 at 1:11 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > On 2018-Nov-17, Amit Kapila wrote: > > > On Sat, Nov 17, 2018 at 4:46 PM Alvaro Herrera <alvherre@2ndquadrant.com> > wrote: > > > > Uh, ouch! Seems to me that this is a high-caliber foot-gun, and will > > > cause nasty suprises when production stats data disappear > inadvertently! > > > > What is the alternative in your mind? > > Well, as I see this interface, it is as if > DELETE FROM ... WHERE queryid = <value> > where passing a NULL value meant to delete *all* rows regardless of > queryid, rather than only those where queryid is NULL. > > > AFAICS, we have below alternatives: > > > > a) Return an error for the NULL value of any argument? > > b) Silently ignore if there is any NULL value argument and don't > > remove any stats. > > c) Just ignore the NULL value parameter and remove the stats based on > > other parameters. > > > Currently, patch implements option (c), but we can do (a) or (b) as > > well, however, that can make the API usage bit awkward. > > I think option d) is to have more functions (seven functions total), and > have them all be strict (i.e. don't do anything if one argument is > NULL). One function takes three arguments, and removes all entries > matching the three. Other functions take two arguments, and remove > everything matching those, ignoring the third (so behaving like the > current NULL). Others take one argument. > > Maybe it doesn't make sense to provide all combinations, so it's less > than seven. But having an interface that's inherently easy to misuse > makes me a bit nervous. > Following are the combinations that are possible and function name as also pg_stat_statements_reset_by_*** userid, dbid queryid userid, dbid userid, queryid dbid, queryid userid, dbid, queryid -- Existing function name with arguments can work. So 6 new functions needs to be added to cover all the above cases, IMO, we may need functions for all combinations, because I feel some user may have the requirement of left out combination, in case if we choose only some combinations. Regards, Haribabu Kommi Fujitsu Australia
Commits
-
Extend pg_stat_statements_reset to reset statistics specific to a
- 43cbedab8ff1 12.0 landed
-
Default monitoring roles
- 25fff40798fc 10.0 cited