Re: [HACKERS] 64-bit queryId?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] 64-bit queryId?
Дата
Msg-id CA+TgmoZJs1LP95KgQycyev3rL3oyxpcfXW_K4yH7C26hTYgYxg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] 64-bit queryId?  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] 64-bit queryId?  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Wed, Oct 4, 2017 at 9:49 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> I am still on the learning curve with pg_stat_statements... This still
> does not look complete to me. pgss_hash_fn only makes use of the last
> four bytes of the query ID. What about computing the hash using as
> also the first four bytes? With the current code, if the last four
> bytes of two queries match then they would be counted together looking
> at pgss_store().

Not really; dynahash won't merge two keys just because their hash
codes come out the same.  But you're right; that's probably not the
best way to do it.   TBH, why do we even have pgss_hash_fn?  It seems
like using tag_hash would be superior.

> I have spotted as well this comment in pg_stat_statements.c:
>     /* Increment the counts, except when jstate is not NULL */
>     if (!jstate)
> I think that this should be "when jstate is NULL".

I think that you're right, but that's unrelated to this patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Amit Khandekar
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] datetime.h defines like PM conflict with external libraries