Re: Add comment explaining why queryid is int64 in pg_stat_statements

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Add comment explaining why queryid is int64 in pg_stat_statements
Дата
Msg-id aCvzJNwetyEI3Sgo@paquier.xyz
обсуждение исходный текст
Ответ на Re: Add comment explaining why queryid is int64 in pg_stat_statements  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления: