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: Peter Eisentraut <peter.eisentraut@2ndquadrant.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>, Haribabu Kommi <kommi.haribabu@gmail.com>
Date: 2018-11-26T12:02:14Z
Lists: pgsql-hackers 
On Fri, Nov 23, 2018 at 4:40 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
>
> On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> On 19/11/2018 06:18, Haribabu Kommi wrote:
>> > Amit suggested another option in another mail, so total viable
>> > solutions that are discussed as of now are,
>> >
>> > 1. Single API with NULL input treat as invalid value
>> > 2. Multiple API to deal with NULL input of other values
>> > 3. Single API with NULL value to treat them as current user, current
>> > database
>> >  and NULL queryid.
>> > 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.
>>
>> Can you show examples of what these would look like?
>
>
> Following are some of the examples how the various options
> work.
>

Do the examples provided by Haribabu helps in understanding the proposal?

-- 
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