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

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
Дата
Msg-id CAJrrPGdu_v6LqSg3Kt6hNiKsC9i-t_EF80OcrcDZYAa-5LPYPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers

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.

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: WAL prefetch
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Desirability of client-side expressions in psql?