| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: 64-bit queryId? |
| Date: | 2017-10-04 14:04:11 |
| Message-ID: | CA+TgmoZJs1LP95KgQycyev3rL3oyxpcfXW_K4yH7C26hTYgYxg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Oct 4, 2017 at 9:49 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-10-04 14:05:47 | Re: datetime.h defines like PM conflict with external libraries |
| Previous Message | Amit Khandekar | 2017-10-04 13:51:40 | Re: UPDATE of partition key |