Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
Дата
Msg-id 20191111083730.GD1418@paquier.xyz
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Julien Rouhaud <julien.rouhaud@free.fr>)
Ответы Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, Sep 11, 2019 at 06:30:22PM +0200, Julien Rouhaud wrote:
> The thing is that pg_stat_statements assigns a 0 queryid in the
> post_parse_analyze_hook to recognize utility statements and avoid
> tracking instrumentation twice in case of utility statements, and then
> compute a queryid base on a hash of the query text.  Maybe we could
> instead fully reserve queryid "2" for utility statements (so forcing
> queryid "1" for standard queries if jumbling returns 0 *or* 2 instead
> of only 0), and use "2" as the identifier for utility statement
> instead of "0"?

Hmm.  Not sure.  At this stage it would be nice to gather more input
on the matter, and FWIW, I don't like much the assumption that a query
ID of 0 is perhaps a utility statement, or perhaps nothing depending
on the state of a backend entry, or even perhaps something else
depending how on how modules make use and define such query IDs.
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Ought to use heap_multi_insert() for pg_attribute/dependinsertions?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Adding a test for speculative insert abort case