Re: query_id, pg_stat_activity, extended query protocol

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: query_id, pg_stat_activity, extended query protocol
Дата
Msg-id ZkVbPs9B1e7I8bwK@paquier.xyz
обсуждение исходный текст
Ответ на Re: query_id, pg_stat_activity, extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Список pgsql-hackers
On Wed, May 15, 2024 at 06:36:23PM +0000, Imseih (AWS), Sami wrote:
>> Okay, that's what I precisely wanted to understand: queryId doesn't have
>> semantics to show the job that consumes resources right now—it is mostly
>> about convenience to know that the backend processes nothing except
>> (probably) this query.
>
> It may be a good idea to expose in pg_stat_activity or a
> supplemental activity view information about the current state of the
> query processing. i.e. Is it parsing, planning or executing a query or
> is it processing a nested query.

pg_stat_activity is already quite bloated with attributes, and I'd
suspect that there are more properties in a query that would be
interesting to track down at a thinner level as long as it mirrors a
dynamic activity of the query.  Perhaps a separate catalog like a
pg_stat_query would make sense, moving query_start there as well?
Catalog breakages are never fun, still always happen because the
reasons behind a backward-incompatible change make the picture better
in the long-term for users.
--
Michael

Вложения

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: CREATE TABLE/ProcessUtility hook behavior change
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Why is citext/regress failing on hamerkop?