Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Tomas Vondra <tomas.vondra@2ndquadrant.com>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Julien Rouhaud <julien.rouhaud@free.fr>
Cc: Michael Paquier <michael@paquier.xyz>, Bruce Momjian <bruce@momjian.us>, Evgeny Efimkin <efimkin@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-02-01T11:30:45Z
Lists: pgsql-hackers
On Fri, Nov 29, 2019 at 09:39:09AM +0100, Julien Rouhaud wrote: >On Fri, Nov 29, 2019 at 7:21 AM Michael Paquier <michael@paquier.xyz> wrote: >> >> On Fri, Nov 29, 2019 at 03:19:49PM +0900, Michael Paquier wrote: >> > On Wed, Nov 13, 2019 at 12:53:09PM +0100, Julien Rouhaud wrote: >> >> I'd really like to have the queryid function available through SQL, >> >> but I think that this specific case wouldn't work very well for >> >> pg_stat_statements' approach as it's working with oid. The query >> >> string in pg_stat_activity is the user provided one rather than a >> >> fully-qualified version, so in order to get that query's queryid, you >> >> need to know the exact search_path in use in that backend, and that's >> >> not something available. >> > >> > Yeah.. So, we have a patch marked as ready for committer here, and it >> > seems to me that we have a couple of issues to discuss more about >> > first particularly this query ID of 0. Again, do others have more >> > any input to offer? > >I just realized that with current infrastructure it's not possible to >display a utility queryid. We need to recognize utility to not >process the counters twice (once in processUtility, once in the >underlying executor), so we don't provide a queryid for utility >statements in parse analysis. Current magic value 0 has the side >effect of showing an invalid queryid for all utilty statements, and >using a magic value different from 0 will just always display that >magic value. We could instead add another field in the Query and >PlannedStmt structs, say "int queryid_flags", that extensions could >use for their needs? > >> And while on it, the latest patch does not apply, so a rebase is >> needed here. > >Yep, I noticed that this morning. I already rebased the patch >locally, I'll send a new version with new modifications when we reach >an agreement on the utility issue. > Well, this patch was in WoA since November, but now that I look at it that might have been wrong - we're clearly waiting for agreement on how to handle queryid for utility commands. I suspect the WoA status might have been driving people away from this thread :-( I've switched the patch to "needs review" and moved it to the next CF. What I think needs to happen is we get a patch implementing one of the proposed solutions, and discuss that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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