Date: Fri, 19 Mar 2021 11:16:50 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Pavel Stehule <pavel.stehule@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	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>
Subject: Re: Feature improvement: can we add queryId for
 pg_catalog.pg_stat_activity view?
Message-ID: <20210319031650.aqy3ad7fpqsudo3b@nol>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210318192349.GD3721@momjian.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20210319031650.aqy3ad7fpqsudo3b%40nol>
Precedence: bulk

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.