Date: Wed, 12 May 2021 23:33:32 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Magnus Hagander <magnus@hagander.net>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Michael Paquier <michael@paquier.xyz>,
	Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Stephen Frost <sfrost@snowman.net>,
	Christoph Berg <myon@debian.org>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: compute_query_id and pg_stat_statements
Message-ID: <20210513033332.GF11075@momjian.us>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210513031613.j47baglf6xl3mgbs@nol>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210513033332.GF11075%40momjian.us>
Precedence: bulk

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.