Re: Add comment explaining why queryid is int64 in pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add comment explaining why queryid is int64 in pg_stat_statements
Date
Msg-id aCvzJNwetyEI3Sgo@paquier.xyz
Whole thread Raw
In response to Re: Add comment explaining why queryid is int64 in pg_stat_statements  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
List pgsql-hackers
On Tue, May 20, 2025 at 02:03:37PM +1200, David Rowley wrote:
> 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.

Hmm.  For the query ID, that's not new, but for the plan ID it is.  So
it seems to me that there could be also an argument for doing all that
in v18 rather than releasing v18 with the plan ID being unsigned,
keeping a maximum of consistency for both of IDs.  AFAIK, this is
something that Lukas's plan storing extension exposes as an int64
value to the user and the SQL interfaces, even if it's true that we
don't expose it in core, yet.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding null patch entry to cfbot/CommitFest
Next
From: Michael Paquier
Date:
Subject: Re: Regression in statement locations