Date: Thu, 13 May 2021 14:07:06 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Christoph Berg <myon@debian.org>, Julien Rouhaud <rjuju123@gmail.com>,
	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>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: compute_query_id and pg_stat_statements
Message-ID: <20210513180706.GG20766@tamriel.snowman.net>
References: <20210513005236.aj7n6b76yjsxythc@nol>
 <20210513011325.GA11075@momjian.us>
 <20210513015700.fp33q5rfvwl2ahfx@nol>
 <20210513030652.GB11075@momjian.us>
 <20210513031613.j47baglf6xl3mgbs@nol>
 <20210513033332.GF11075@momjian.us>
 <20210513040342.fouh7ryglrfgxglu@nol>
 <20210513144143.GG11075@momjian.us>
 <YJ1kYeKvYBk0cxti@msg.df7cb.de>
 <20210513175947.GP11075@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="pVWdpJeG5OG8Gd6G"
Content-Disposition: inline
In-Reply-To: <20210513175947.GP11075@momjian.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20210513180706.GG20766%40tamriel.snowman.net>
Precedence: bulk


--pVWdpJeG5OG8Gd6G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, May 13, 2021 at 07:39:45PM +0200, Christoph Berg wrote:
> > Re: Bruce Momjian
> > > Well, now that we have clear warnings when it is misconfigured,
> > > especially when querying the pg_stat_statements view, are these
> > > complaints still valid?   Also, how is modifying
> > > shared_preload_libraries zero-config, but modifying
> > > shared_preload_libraries and compute_query_id a huge burden?
> >=20
> > It's zero-config in the sense that if you want to have
> > pg_stat_statements, loading that module via shared_preload_libraries
> > is just natural.

Not sure about natural but it's certainly what folks have at least
become used to.  We should be working to eliminate it though.

> > Having to set compute_query_id isn't natural. It's a setting with a
> > completely different name, and the connection of pg_stat_statements to
> > compute_query_id isn't obvious.
> >=20
> > The reasoning with "we have warnings and stuff" might be ok if
> > pg_stat_statements were a new thing, but it has worked via
> > shared_preload_libraries only for the last decade, and requiring
> > something extra will confuse probably every single user of
> > pg_stat_statements out there.

As we keep seeing, over and over.  The ongoing comments claiming that
it's "just" a minor additional configuration tweak fall pretty flat when
you consider the number of times it's already been brought up, and who
it has been brought up by.

> > Perhaps worse, note that these warnings will likely first be seen by
> > the end users of databases, not by the admin performing the initial
> > setup or upgrade, who will not be able to fix the problem themselves.

I don't think this is appreciated anywhere near well enough.  This takes
existing perfectly working configurations and actively breaks them in a
manner that isn't obvious and isn't something that an admin would have
any idea about until after they've upgraded and then started trying to
query the view.  That's pretty terrible.

> Well, but doing this extra configuration, the query id shows up in a lot
> more places.  I can't imagine how this could be done cleanly without
> requiring extra configuration, unless the query_id computation was
> cheaper to compute and we could enable it by default.

There's a ridiculously simple option here which is: drop the idea that
we support an extension redefining the query id and then just make it
on/off with the default to be 'on'.  If people actually have a problem
with it being on and they don't want to use pg_stat_statements then they
can turn it off.  This won't break any existing configs that are out
there in the field and avoids the complexity of having some kind of
'auto' config.  I do agree with the general idea of wanting to be
extensible but I'm not convinced that, in this particular case, it's
worth all of this.  I'm somewhat convinced that having a way to disable
the query id is useful in limited cases and if people want a way to do
that, then we can give that to them in a straightfoward way that doens't
break things.

Thanks,

Stephen

--pVWdpJeG5OG8Gd6G
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJgnWrJAAoJEO1sijiDR2RVQYMQAI+BwFMIWg5+SqP70Z73QFax
Y9UoE6l9vS2Lwj3CKjMiQEvCa/muiLdRZt/k+6wHm05ndJ7jnMyMJY5E/PYtuQzM
VPjPf5tOLFgVgamVdjV1kmoyDK99TdtUquCRfhpVWhvVaoCf9XuAJB6/09H3ioSd
QusbQrVitTkhnSE2cldOLT/mGTkCXQMSygy5MEQ/q5+/fvglekoMrPuKyBOX5Iqf
2Bwmn5l5X9ediWSgHvajrjlOxt3+YggIQCIGWhy9gnyEirwLeiHpLYD65VMjHFdE
pRdh8yM91GVg/ck7ekUGzBncZuBlD/ZpjPkLtfFNx97DxCUlvagTx0ZERLEyMBqd
KSbHrSuBBeTvXJx3FAZMAx38ETQVjyNOWPvsOjddhedM1wkFID9mWcb6049Uus29
ve8S88lSh/KJ5klHdrxqEn/XQhEMcZpyJwCkl+gYbUXmj9ACFJSkjpJOJKpJblFi
a1QdsmsZ4YuB9vHM35WGdRztrFH5wPwi+jHosf/FCekt6QFSaYgPUCx04Zcqm2Sq
crf+c2w2GVqc5MqvB19XoPkq04+UPCyMFXQB7Z8UbJkYGyMSmgW335P/ZXsdIbp0
rjr7eOsFxhTbKZtVpTI3iEJdSMTvomfcG0bG+bbXBuG6qEWCK1UYkHvjWOASZs/f
Who3DspoMEzpJIjnNGh1
=0CBb
-----END PGP SIGNATURE-----

--pVWdpJeG5OG8Gd6G--