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-10 08:04:30
Message-ID: CAJrrPGcrScWKSB-NVBw_EUwOtvsnsrQo-F28b=1+k6Q=nueVCg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 10, 2018 at 12:26 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Sun, Jul 8, 2018 at 11:48 AM, Haribabu Kommi
> <kommi(dot)haribabu(at)gmail(dot)com> wrote:
> >
> > 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.
>
> Though I've not read the whole code of pgss_hash_string(), ISTM that
> the function can return 0. Otherwise, the following code is unnecessary
> after queryid is assigned by hash_any_extended(),
> in pgss_post_parse_analyze().
>
> /*
> * If we are unlucky enough to get a hash of zero, use 1 instead, to
> * prevent confusion with the utility-statement case.
> */
> if (query->queryId == UINT64CONST(0))
> query->queryId = UINT64CONST(1);
>
> > If yes, then we may need same handling to utility statements
> > similar like normal statements but with queryID as 2 for utility
> statements.
>
> That's possible, but I think that it's better to get rid of such corner
> case at all.
>

QueryID 2 is used in case if the generated hash value is 0 for utility
statements
to give difference with normal statements and also used the UINT64CONST
macro as per the earlier comment.

updated patch attached. This patch needs to be applied on top of the ACL
permissions revert patch. ACL revert patch also in this thread.

Regards,
Haribabu Kommi
Fujitsu Australia

Attachment Content-Type Size
0002-pg_stat_statements_reset-to-reset-specific-query-use_v4.patch application/octet-stream 19.1 KB
0001-Revoke-pg_stat_statements_reset-permissions_v2.patch application/octet-stream 2.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-07-10 08:16:30 Re: Non-reserved replication slots and slot advancing
Previous Message Iwata, Aya 2018-07-10 08:03:44 RE: hostorder and failover_timeout for libpq