Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 05:51:49PM +0800, Julien Rouhaud wrote:
> On Wed, May 12, 2021 at 11:42:12AM +0200, Pavel Stehule wrote:
> > this check just can check if there is "any" query-id provider. In this
> > context is not important if it is buildin or external
>
> Yes, the idea is that if you execute "SELECT * FROM pg_stat_statements" or
> similar, then if the executing query itself doesn't have a queryid then
> it's very likely that you didn't configure compute_query_id or an alternative
> query_id implementation properly. And loudly complaining seems like the right
> thing to do.

I understand the desire to make pg_stat_statements require minimal
configuration, but frankly, if the server-side variable query id API is
confusing, I think we have done more harm than good.

The problem with compute_query_id=auto is that there is no way to know
if the query id is actually enabled, unless you guess from the installed
extensions, or we add another variable to report that, and maybe another
variable to control the provier, unless we require turning
compute_query_id=off if you are using custom query id computation. What
if it is auto, and pg_stat_statments is installed, and you want to use a
custom query id computation --- what happens? As you can see, this is
all becoming very complicated.

I think we might be just as well to go with compute_query_id=on/off, and
just complain loudly from CREATE EXTENSION, or in the server logs on
server start via shared_preload_libraries, or when querying
pg_stat_statements system view. We simply say to change
compute_query_id=on or to provide a custom query id implementation.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.