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

  1. Extend pg_stat_statements_reset to reset statistics specific to a

  2. Default monitoring roles