Greetings, * Bruce Momjian (br...@momjian.us) wrote: > 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?
+1 on this approach. I agree that we should avoid having to make every new user and every user who is upgrading with pg_stat_statements installed have to go twiddle this parameter. Thanks, Stephen
signature.asc
Description: PGP signature
