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
Дата
в 06:12:36
Msg-id
aCvzJNwetyEI3Sgo@paquier.xyz
Список
Дерево обсуждения
Re: Add comment explaining why queryid is int64 in pg_stat_statements Shaik Mohammad Mujeeb <mujeeb.sk@zohocorp.com>
Re: Add comment explaining why queryid is int64 in pg_stat_statements wenhui qiu <qiuwenhuifx@gmail.com>
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 по дате отправления
От: Tom Lane
Дата:
От: Lukas Fittl
Дата:
FAQ