Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
От | Tomas Vondra |
---|---|
Тема | Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | 20200201113045.x4qj36uvt34ymwiy@development обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview? (Julien Rouhaud <julien.rouhaud@free.fr>) |
Ответы |
Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?
|
Список | 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
В списке pgsql-hackers по дате отправления: