From: Julien Rouhaud <rjuju123@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: torikoshia <torikoshia@oss.nttdata.com>
Cc: Atsushi Torikoshi <atorik@gmail.com>
Cc: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Evgeny Efimkin <efimkin@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Date: Fri, 19 Mar 2021 11:16:50 +0800
Message-ID: <20210319031650.aqy3ad7fpqsudo3b@nol> (raw)
In-Reply-To: <20210318192349.GD3721@momjian.us>
References: <3519983.1615996898@sss.pgh.pa.us>
<CAFj8pRBwOBo_3R3zNc+E2Z+skzRd+dwNVRLfn95R2P=qscp-SQ@mail.gmail.com>
<20210317162444.GD16650@momjian.us>
<20210317164907.c4uogoqvchnwcnjy@nol>
<CA+Tgmoa5r2yxtuyHiYM3dVVEorr3vbVexYm9m+maMMiZtA25uA@mail.gmail.com>
<20210317223216.GE16650@momjian.us>
<20210317232956.veah6bax3mespdtq@nol>
<20210318134729.GA8529@momjian.us>
<20210318180656.3aat6jkbs7ylcg4k@nol>
<20210318192349.GD3721@momjian.us>
On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote:
> On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
>
> The above text is the part that made me think an extension could display
> a query id even if disabled by the GUC.
With the last version of the patch I sent it was the case.
> Oh, OK. I can see an extension setting the query id on its own --- we
> can't prevent that from happening. It is probably enough to tell
> extensions to honor the GUC, since they would want it enabled so it
> displays in pg_stat_activity and log_line_prefix.
Ok. So no new hook, and we keep using post_parse_analyze_hook as the official
way to have custom queryid implementation, with this new behavior:
> > - if some extension calculates a queryid during post_parse_analyze_hook, we
> > will always reset it.
>
> OK, good.
Now that I'm back on the code I remember why I did it this way. It's
unfortunately not really possible to make things work this way.
pg_stat_statements' post_parse_analyze_hook relies on a queryid already being
computed, as it's where we know where the constants are recorded. It means:
- we have to call post_parse_analyze_hook *after* doing core queryid
calculation
- if users want to use a third party module to calculate a queryid, they'll
have to make sure that the module's post_parse_analyze_hook is called
*before* pg_stat_statements' one.
- even if they do so, they'll still have to pay the price of core queryid
calculation
So it would be very hard to configure and will be too expensive. I think that
we have to choose to either we make compute_query_id only trigger core
calculation (like it was in previous patch version), or introduce a new hook.
> I think compute_query_id works, and is shorter.
WFM.
> OK, good to know. I can run some tests here if people would like me to.
+1. A read only pgbench will be some kind od worse case scenario that can be
used I think.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rjuju123@gmail.com, bruce@momjian.us, robertmhaas@gmail.com, pavel.stehule@gmail.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, michael@paquier.xyz, torikoshia@oss.nttdata.com, atorik@gmail.com, tatsuro.yamada.tf@nttcom.co.jp, tomas.vondra@2ndquadrant.com, efimkin@yandex-team.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
In-Reply-To: <20210319031650.aqy3ad7fpqsudo3b@nol>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox