Re: Add comment explaining why queryid is int64 in pg_stat_statements

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>

To: Peter Eisentraut <peter@eisentraut.org>

Cc: Michael Paquier <michael@paquier.xyz>, 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-20T02:03:37Z

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

v1-0001-Change-internal-queryid-type-to-int64.patch (application/octet-stream) patch v1-0001

On Tue, 20 May 2025 at 03:05, Peter Eisentraut <peter@eisentraut.org> wrote:
> Or why not store query IDs as int64_t
> internally, too?

I had the same thought. Changing to int64 seems like a good and less
bug-prone tidy-up. I expected we ended up with uint64 as the previous
type was uint32, and uint64 is the natural selection for widening that
to 64 bits.

Aside from the struct field types changing for Query.queryId,
PlannedStmt.queryId and PgBackendStatus.st_query_id, the
external-facing changes are limited to:

1. pgstat_report_query_id() now returns int64 instead of uint64
2. pgstat_get_my_query_id()  now returns int64 instead of uint64
3. pgstat_report_query_id()'s first input parameter is now int64

If we were to clean this up, then I expect it's fine to wait until
v19, as it's not really a problem that's new to v18.

David