Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Julien Rouhaud <rjuju123@gmail.com>, Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@alvh.no-ip.org>, 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-12T19:54:43Z
Lists: pgsql-hackers
On Mon, Oct 12, 2020 at 02:26:15PM -0400, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > I don't really understand how a version number helps. It's not like > > there is going to be a v2 that is in all ways better than v1. If there > > are different algorithms here, they are going to be customized for > > different needs. > > Yeah, I agree --- a version number is the wrong way to think about this. > It's gonna be more like algorithm foo versus algorithm bar versus > algorithm baz, where each one is better for a specific set of use-cases. > Julien already noted the point about hashing object OIDs versus object > names; one can easily imagine disagreeing with pg_stat_statement's > choices about ignoring values of constants; other properties of statements > might be irrelevant for some use-cases; and so on. The version number was to invalidate _all_ query hashes if the algorithm is slightly modified, rather than invalidating just some of them, which could lead to confusion. The idea of selectable hash algorithms is nice if people feel there is sufficient need for that. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
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