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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
