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

On Sun, Jul 8, 2018 at 11:48 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
>
> On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi <kommi.haribabu@gmail.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.