Re: Add comment explaining why queryid is int64 in pg_stat_statements

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Sami Imseih <samimseih@gmail.com>

Cc: David Rowley <dgrowleyml@gmail.com>, Lukas Fittl <lukas@fittl.com>, Peter Eisentraut <peter@eisentraut.org>, Shaik Mohammad Mujeeb <mujeeb.sk@zohocorp.com>, ilyaevdokimov <ilya.evdokimov@tantorlabs.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, mujeebskdev <mujeeb.sk.dev@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-05-21T04:43:11Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Change internal plan ID type from uint64 to int64
- e050af28686e 18.0 landed
Change internal queryid type from uint64 to int64
- c3eda50b0648 18.0 landed
pg_stat_statements: Widen query IDs from 32 bits to 64 bits.
- cff440d36869 11.0 cited

Attachments

v2-0001-Change-internal-queryid-type-to-int64.patch (text/x-diff) patch v2-0001
v2-0002-Change-type-of-plan-IDs-from-uint64-to-int64.patch (text/x-diff) patch v2-0002

On Tue, May 20, 2025 at 10:35:39AM -0500, Sami Imseih wrote:
> 1/ this was missed in pg_stat_statements
> ./contrib/pg_stat_statements/pg_stat_statements.c:    uint64
> saved_queryId = pstmt->queryId;

Right.  Some greps based on "queryid" and "query_id" point that this
is the last reference to uint in the tree.

> 2/ Should "DatumGetInt64(hash_any_extended(......" be turned into a
> macro since it's used in
> several places? Also, we can add a comment in the macro such as
> "
> Output the queryId as an int64 rather than a uint64, to match the
> BIGINT column used to emit
> queryId in system views
> "

We are talking about two places in queryjumblefuncs.c.  Leaving the
code as in David's original proposal is fine IMO.  Adding a comment
about the implied uint64 -> int64 conversion when calling
hash_any_extended() sounds like a good idea to document what we want
from the hash.

I've had a closer look at David's patch, and I did not spot other
places that required similar adjustments.  I may have missed
something, of course.

David, how would you like to move on with this patch set?  I can take
responsibility for both patches as the plan ID change can qualify as
an open item.
--
Michael