Horton

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>, Magnus Hagander <magnus@hagander.net>, sk@zsrv.org, 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-20T03:06:00Z
Lists: pgsql-hackers 
On Mon, Nov 19, 2018 at 10:48 AM Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> On Mon, Nov 19, 2018 at 1:37 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>
>> On 2018-Nov-19, Michael Paquier wrote:
>>
>> > On Mon, Nov 19, 2018 at 10:41:22AM +1100, Haribabu Kommi wrote:
>> > > 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.
>> >
>> > That's bloating the interface in my opinion.
>>
>> I understand.
>>
>> Let's call for a vote from a larger audience.  It's important to get
>> this interface right, ISTM.
>
> 4. Single API with -1 as invalid value, treat NULL as no matching. (Only problem
>  with this approach is till now -1 is also a valid queryid, but setting -1 as queryid
> needs to be avoided.
>

Hmm, can we use 0 as default value without any such caveat?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. Extend pg_stat_statements_reset to reset statistics specific to a

  2. Default monitoring roles