From: Bruce Momjian <bruce@momjian.us>
To: Julien Rouhaud <rjuju123@gmail.com>
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: Thu, 18 Mar 2021 15:23:49 -0400
Message-ID: <20210318192349.GD3721@momjian.us> (raw)
In-Reply-To: <20210318180656.3aat6jkbs7ylcg4k@nol>
References: <20210317154023.GB16650@momjian.us>
<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>
On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
> On Thu, Mar 18, 2021 at 09:47:29AM -0400, Bruce Momjian wrote:
> > On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote:
> > > 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.
The above text is the part that made me think an extension could display
a query id even if disabled by the GUC.
> > The docs are going to say that you have to enable compute_queryid to see
> > the query id in pg_stat_activity and log_line_prefix, but if you install
> > an extension, the query id will be visible even if you don't have
> > compute_queryid enabled. I think you need to only honor the hook if
> > compute_queryid is enabled, and update the pg_stat_statements docs to
> > say you have to enable compute_queryid for pg_stat_statements to work.
>
> I'm confused, what you described really looks like what I described.
>
> Let me try to clarify:
>
> - if compute_queryid is off, a queryid should never be seen no matter how hard
> an extension tries
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.
> - if compute_queryid is on, the calculation will be done by the core
> (using pgss JumbeQuery) unless an extension computed one already. The only
> way to know what algorithm is used is to check the list of extension loaded.
OK.
> - if some extension calculates a queryid during post_parse_analyze_hook, we
> will always reset it.
OK, good.
> Is that the approach you want?
Yes, I think so.
> Note that the only way to not honor the hook is iff the new GUC is disabled is
> to have a new queryid_hook, as we can't stop calling post_parse_analyze_hook if
> the new GUC is off, and we don't want to pay the queryid calculation overhead
> if the admin explicitly said it wasn't needed.
Right, let's just get the extensions to honor the GUC --- we don't need
to block them or anything.
> > Also, should it be compute_queryid or compute_query_id?
>
> Maybe compute_query_identifier?
I think compute_query_id works, and is shorter.
> > Also, the overhead of computing the query id was reported as 2% --- that
> > seems quite high for what it does. Do we know why it is so high?
>
> The 2% was a worst case scenario, for a query with a single join over
> ridiculously small pg_class and pg_attribute, in read only. The whole workload
> was in shared buffers so the planning and execution is quite fast. Adding some
> complexity in the query really limited the overhead.
>
> Note that this was done on an old laptop with quite slow CPU. Maybe
> someone with a better hardware than a 5/6yo laptop could get some more
> realistic results (I unfortunately don't have anything to try on).
OK, good to know. I can run some tests here if people would like me to.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
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: bruce@momjian.us, rjuju123@gmail.com, 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: <20210318192349.GD3721@momjian.us>
* 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