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

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: sk(at)zsrv(dot)org, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query
Date: 2018-07-08 02:48:19
Message-ID: CAJrrPGdu_v6LqSg3Kt6hNiKsC9i-t_EF80OcrcDZYAa-5LPYPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
> >
> > Update patch attached.
>
> + if (userid != 0 && dbid != 0 && queryid != 0)
>
> UINT64CONST() should be used for the constant for queryid?
>

OK.

> It's rare case, but 0 can be assigned as valid queryid. Right?
>

But for normal queries, in post parse analyze function, the queryID
is calculated and it set to 1, in case if the calculation becomes 0.
But for the utility statements, the calculation is done using the
pgss_hash_string() function. I am not sure whether this function
can return 0.

If yes, then we may need same handling to utility statements
similar like normal statements but with queryID as 2 for utility statements.

comments?

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-07-08 07:28:37 Re: Desirability of client-side expressions in psql?
Previous Message Tomas Vondra 2018-07-07 21:47:47 Re: WAL prefetch