|From:||Julien Rouhaud <rjuju123(at)gmail(dot)com>|
|To:||Bruce Momjian <bruce(at)momjian(dot)us>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com>, Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Evgeny Efimkin <efimkin(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> On Wed, Mar 17, 2021 at 04:04:44PM -0400, Robert Haas wrote:
> > On Wed, Mar 17, 2021 at 12:48 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > > I originally suggested to make it clearer by having an enum GUC rather than a
> > > boolean, say compute_queryid = [ none | core | external ], and if set to
> > > external then a hook would be explicitely called. Right now, "none" and
> > > "external" are binded with compute_queryid = off, and depends on whether an
> > > extension is computing a queryid during post_parse_analyse_hook.
> > I would just make it a Boolean and have a hook. The Boolean controls
> > whether it gets computed at all, and the hook lets an external module
> > override the way it gets computed.
> OK, is that what everyone wants? I think that is what the patch already
Note exactly. Right now a custom queryid can be computed even if
compute_queryid is off, if some extension does that in post_parse_analyze_hook.
I'm assuming that what Robert was thinking was more like:
queryId = queryid_hook(...);
queryId = JumbeQuery(...);
queryId = 0;
And that should be done *after* post_parse_analyse_hook so that it's clear that
this hook is no longer the place to compute queryid.
Is that what should be done?
> I think having multiple queryids used in a single cluster is much too
> confusing to support. You would have to label and control which queryid
> is displayed by pg_stat_activity and log_line_prefix, and that seems too
> confusing and not useful.
|Next Message||Tom Lane||2021-03-17 23:36:46||Re: replication slot stats memory bug|
|Previous Message||Andres Freund||2021-03-17 23:25:19||Re: replication slot stats memory bug|