Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: sk@zsrv.org, vik.fearing@2ndquadrant.com, Haribabu Kommi <kommi.haribabu@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Michael Paquier <michael@paquier.xyz>, Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Euler Taveira <euler@timbira.com.br>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Simon Riggs <simon@2ndquadrant.com>, Dave Page <dpage@pgadmin.org>
Date: 2018-11-29T02:57:02Z
Lists: pgsql-hackers
On Wed, Nov 28, 2018 at 7:13 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > On 2018-Nov-28, Amit Kapila wrote: > > > The problem with this idea is that if someone specifies a particular > > parameter using query and the query doesn't return any parameters, > > then it can lead to inadvertent behavior. For example, if user uses > > something like pg_stat_statements_reset(<valid_user_id>, > > <valid_db_id>, SELECT s.queryid FROM pg_stat_statements AS s WHERE > > s.query = 'SELECT $1 AS "ONE"'); now, if the query doesn't return any > > row, we will remove the stats for all queries that belong to > > (userid,dbid). It could be surprising for some users, that's why we > > came up with option-4 where we keep the default value of parameters as > > 0. > > Right, I think option 4 is a clear improvement over option 1. I can get > behind that one. Since not many people care to vote, I think this tips > the scales enough to that side. > Agreed. Hari, can you change the patch as per the requirements of option-4. > Thanks for your patience. > No problem. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Extend pg_stat_statements_reset to reset statistics specific to a
- 43cbedab8ff1 12.0 landed
-
Default monitoring roles
- 25fff40798fc 10.0 cited