| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>, ilyaevdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, mujeebskdev <mujeeb(dot)sk(dot)dev(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
| Date: | 2025-05-20 03:12:36 |
| Message-ID: | aCvzJNwetyEI3Sgo@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lukas Fittl | 2025-05-20 03:43:25 | Re: Add comment explaining why queryid is int64 in pg_stat_statements |
| Previous Message | Tom Lane | 2025-05-20 03:11:33 | Re: Adding null patch entry to cfbot/CommitFest |