On Mon, Apr 26, 2021 at 05:34:30PM +0200, Christoph Berg wrote: > Re: Peter Eisentraut > > > Agreed. If pg_stat_statements were zero-configuration today then > > > this would be an annoying new burden, but it isn't. > > > > I think people can understand "add pg_stat_statements to > > shared_preload_libraries" and "install the extension". You have to turn it > > on somehow after all. > > Fwiw, I'd claim that pg_stat_statements *is* zero-configuration today. > You just have to load the module (= shared_preload_libraries), and it > will start working. Later you can run CREATE EXTENSION to actually see > the stats, but they are already being collected in the background. > > > Now there is the additional burden of turning on this weird setting that no > > one understands. That's a 50% increase in burden. > > > > And almost no one will want to use a nondefault setting. > > > > pg_stat_statements is pretty popular. I think leaving in this requirement > > will lead to widespread confusion and complaints. > > Ack, please make the default config (i.e. after setting > shared_preload_libraries) > do something sensible. Having to enable some "weird" internal other setting > will be very hard to explain to users. > > Fwiw, I'd even want to have pg_stat_statements enabled in core by > default. That would awesome UX. (And turning off could be as simple as > setting compute_query_id=off.)
Techically, pg_stat_statements can turn on compute_query_id when it is loaded, even if it is 'off' in postgresql.conf, right? And pg_stat_statements would know if an alternate hash method is being used, right? This is closer to Magnus's idea of having a three-value compute_query_id, except is it more controlled by pg_stat_statements. Another idea would be to throw a user-visible warning if the pg_stat_statements extension is loaded and compute_query_id is off. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
