From: Bruce Momjian <bruce@momjian.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Christoph Berg <myon@debian.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: compute_query_id and pg_stat_statements
Date: Wed, 12 May 2021 23:33:32 -0400
Message-ID: <20210513033332.GF11075@momjian.us> (raw)
In-Reply-To: <20210513031613.j47baglf6xl3mgbs@nol>
References: <20210512093026.ur43cu3c46eshbew@nol>
<20210512.183927.600535883807655721.horikyota.ntt@gmail.com>
<CAFj8pRCfxtRCoT10wyDAGq6cuW3oVfEJ_JUjEGW_jBs=tpPYnA@mail.gmail.com>
<20210512095149.kqbnhe72uijfwi2r@nol>
<20210513003618.GA26043@momjian.us>
<20210513005236.aj7n6b76yjsxythc@nol>
<20210513011325.GA11075@momjian.us>
<20210513015700.fp33q5rfvwl2ahfx@nol>
<20210513030652.GB11075@momjian.us>
<20210513031613.j47baglf6xl3mgbs@nol>
On Thu, May 13, 2021 at 11:16:13AM +0800, Julien Rouhaud wrote:
> On Wed, May 12, 2021 at 11:06:52PM -0400, Bruce Momjian wrote:
> > On Thu, May 13, 2021 at 09:57:00AM +0800, Julien Rouhaud wrote:
> >
> > > source? What if you have for instance pg_stat_statements, pg_stat_kcache,
> > > pg_store_plans and pg_wait_sampling installed? All those extensions need a
> > > query_id (or at least benefit from it for pg_wait_sampling), is there any value
> > > to give a full list of all the modules that would enable compute_query_id?
> >
> > Well, we don't have any other cases where the source of the change is
> > this indeterminate, so I don't really have a suggestion. I think this
> > does highlight another case where 'auto' just isn't a good fit for our
> > API.
>
> It may depends on your next question
>
> > > I'm assuming that anyone wanting to install any of those extensions (or any
> > > similar one) is fully aware that they aggregate metrics based on at least a
> > > query_id. If they don't, well they probably never read any documentation since
> > > postgres 9.2 which introduced query normalization, and I doubt that they will
> > > be interested in having access to the information anyway.
> >
> > My point is that we are changing a setting from an extension, and if you
> > look in pg_setting, it will say "default"?
>
> No, it will say "on". What the patch I sent implements is:
I was asking what pg_settings.source will say:
SELECT name, soource FROM pg_settings;
> - compute_query_id = on means it was either explicitly set to on, or
> automatically set to on if it was allowed to (so initially set to auto). It
> means you know whether core query_id calculation is enabled or not, you can
> know looking at the reset value it it was changed by an extension, you just
> don't know which one(s).
>
> - compute_query_id = auto means that it can be set to on, it just wasn't yet,
> so it's off, and may change if you have an extension that can be dynamically
> loaded and request for core query_id calculation to be enabled
So, it is 'off', but not set to 'off' in the GUC sense --- just off as
in not being computed. You can see the confusion in my just reading
that sentence.
> - compute_query_id = off means it's off
>
> > If the user already has to edit postgresql.conf to set
> > shared_preload_libraries, I still don't see why having them set
> > compute_query_id at the same time is a significant problem and a reason
> > to distort our API to do 'auto'.
>
> Looking at the arguments until now my understanding is that it's because "no
> one will read the doc anyway".
How do they know to set shared_preload_libraries then? We change the
user API all the time, especially in GUCs, and even rename them, but for
some reason we don't think people using pg_stat_statements can be
trusted to read the release notes and change their behavior. I just
don't get it.
--
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, pavel.stehule@gmail.com, horikyota.ntt@gmail.com, magnus@hagander.net, masao.fujii@oss.nttdata.com, michael@paquier.xyz, andres@anarazel.de, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, sfrost@snowman.net, myon@debian.org, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
Subject: Re: compute_query_id and pg_stat_statements
In-Reply-To: <20210513033332.GF11075@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