Horton

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

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, 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: 2020-10-18T03:01:42Z
Lists: pgsql-hackers 
On 2020-Oct-17, Tom Lane wrote:

> Fair point, but if we allow several different values to be set in
> different sessions, what ends up happening in pg_stat_statements?
> 
> On the other hand, maybe that's just a matter for documentation.
> "If the 'same' query is processed with two different queryID settings,
> that will generally result in two separate table entries, because
> the same ID hash is unlikely to be produced in both cases".

Wait ... what?  I've been thinking that this GUC is just to enable or
disable the computation of query ID, not to change the algorithm to do
so.  Do we really need to allow different algorithms in different
sessions?

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'