Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Bruce Momjian <bruce@momjian.us>, Hannu Krosing <hannuk@google.com>, Robert Haas <robertmhaas@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 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-04-01T15:05:24Z
Lists: pgsql-hackers
On Wed, Mar 31, 2021 at 11:18:45AM -0300, Alvaro Herrera wrote: > On 2021-Mar-31, Bruce Momjian wrote: > > > > I assume it is since Alvaro didn't reply. I am planning to apply this > > soon. > > I'm afraid I don't know enough about how parallel query works to make a > good assessment on this being a good approach or not -- and no time at > present to figure it all out. I'm far from being an expert either, but at the time I wrote it and looking at the code around it probably seemed sensible. We could directly call pgstat_get_my_queryid() in ExecSerializePlan() rather than passing it from the various callers though, at least there would be a single source for it.
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