Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, sk@zsrv.org, vik.fearing@2ndquadrant.com, Haribabu Kommi <kommi.haribabu@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, 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-29T05:56:08Z
Lists: pgsql-hackers 
On Thu, Nov 29, 2018 at 09:09:48AM +0530, Amit Kapila wrote:
> On Thu, Nov 29, 2018 at 8:46 AM Michael Paquier <michael@paquier.xyz> wrote:
>> With option 4 (as defined in [1]), the database ID or the user ID set to
>> 0 means that we don't apply any filter on them, which is sensible.  Now,
>> we have query IDs which can be set to 0, like parseable utility
>> statements.
>
> I think we ensure that queryId won't be 0 for utility statements.

Oh, pgss_store() makes sure to enforce the query ID which has been
calculated in the post-analyze hook.  That's a bit weird to be honest.

>>  When a query ID is set to 0, does this mean that all query
>> IDs matching 0 are reset?  Or does that mean that we don't filter out by
>> query ID?
>>
> 
> It means the later one "We don't apply any filter for queryId.".

Seems like it will be possible to live happily with option 4 then.
--
Michael

Commits

  1. Extend pg_stat_statements_reset to reset statistics specific to a

  2. Default monitoring roles