Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>, Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Michael Paquier <michael@paquier.xyz>, torikoshia <torikoshia@oss.nttdata.com>, Atsushi Torikoshi <atorik@gmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Evgeny Efimkin <efimkin@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-17T20:04:44Z
Lists: pgsql-hackers 
On Wed, Mar 17, 2021 at 12:48 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> I originally suggested to make it clearer by having an enum GUC rather than a
> boolean, say compute_queryid = [ none | core | external ], and if set to
> external then a hook would be explicitely called.  Right now, "none" and
> "external" are binded with compute_queryid = off, and depends on whether an
> extension is computing a queryid during post_parse_analyse_hook.

I would just make it a Boolean and have a hook. The Boolean controls
whether it gets computed at all, and the hook lets an external module
override the way it gets computed.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Clarify description of pg_stat_statements columns

  2. Fix wording in description of pg_stat_statements.toplevel

  3. Mention that toplevel is part of pg_stat_statements key.

  4. adjust query id feature to use pg_stat_activity.query_id

  5. Update copyright for 2021

  6. Take the statistics collector out of the loop for monitoring backends'