Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bruce Momjian <bruce@momjian.us>
Cc: Julien Rouhaud <rjuju123@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, torikoshia <torikoshia@oss.nttdata.com>, Atsushi Torikoshi <atorik@gmail.com>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Robert Haas <robertmhaas@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Evgeny Efimkin <efimkin@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-06T05:34:58Z
Lists: pgsql-hackers
On Mon, Oct 05, 2020 at 11:23:50PM -0400, Bruce Momjian wrote: > On Tue, Oct 6, 2020 at 11:11:27AM +0800, Julien Rouhaud wrote: >> Maybe we could add a new hook for only queryid computation, and add a >> GUC to let people choose between no queryid computed, core computation >> (current pg_stat_statement) and 3rd party plugin? > > That all seems very complicated. If we go in that direction, I suggest > we just give up getting any of this into core. A GUC would have at least the advantage to make the computation consistent for any system willing to consume it, with the option to not pay any potential performance impact, though I have to admit that just moving the query ID computation of PGSS into core may not be the best option as a query ID of 0 means the same thing for a utility, for an initialization, and for a backend running a query with an unknown value, but that could be worked out. FWIW, I think that adding the system ID in the hash is too restrictive, as it could be interesting for users to do stat comparisons across multiple systems running the same major version. It would be better to not give any strong guarantee that the query ID computed will remain consistent across major versions so as it is possible to keep improving it. Also, if nothing has been done that changes the hashing computation, I see little benefit in forcing a breakage by adding something like PG_MAJORVERSION_NUM or such in the hash computation. -- Michael
Commits
-
Clarify description of pg_stat_statements columns
- b4deefc39b93 15.0 landed
- 3b57d5af7435 14.0 landed
-
Fix wording in description of pg_stat_statements.toplevel
- f9e6d00df029 14.0 landed
-
Mention that toplevel is part of pg_stat_statements key.
- 7531fcb1fcf5 14.0 landed
-
adjust query id feature to use pg_stat_activity.query_id
- 9660834dd8bf 14.0 landed
-
Update copyright for 2021
- ca3b37487be3 14.0 cited
-
Take the statistics collector out of the loop for monitoring backends'
- b13c9686d084 8.2.0 cited