Re: Add comment explaining why queryid is int64 in pg_stat_statements

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>

To: Julien Rouhaud <rjuju123@gmail.com>

Cc: Michael Paquier <michael@paquier.xyz>, 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-20T11:28:17Z

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

On Tue, 20 May 2025 at 18:12, Julien Rouhaud <rjuju123@gmail.com> wrote:
> I don't think it was discussed, but why not go the other way, keep everything
> as uint64 and expose an uint64 datatype at the SQL level instead?  That's
> something I actually want pretty often so I would be happy to have that
> natively, whether it's called bigoid, oid8 or anything else.  That's probably
> too late for pg18 though.

Certainly, a bit late, yes. It basically requires implementing
unsigned types on the SQL level. I believe there are a few sunken
ships along that coastline, and plenty of history in the archives if
you want to understand some of the difficulties.

David