Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lb3Fu-0006bk-Cl for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Apr 2021 15:34:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lb3Fs-0000et-VL for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Apr 2021 15:34:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lb3Fs-0000em-OO for pgsql-hackers@lists.postgresql.org; Mon, 26 Apr 2021 15:34:36 +0000 Received: from feynman.df7cb.de ([195.49.152.168]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lb3Fo-0001qn-QC for pgsql-hackers@lists.postgresql.org; Mon, 26 Apr 2021 15:34:35 +0000 Received: from msg.df7cb.de (unknown [IPv6:2a02:908:1478:7c00:8d3d:f292:ea75:555]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) by feynman.df7cb.de (Postfix) with ESMTPSA id 4FTTTf3Wxnz3DwT; Mon, 26 Apr 2021 17:34:30 +0200 (CEST) Date: Mon, 26 Apr 2021 17:34:30 +0200 From: Christoph Berg To: Peter Eisentraut Cc: Tom Lane , Bruce Momjian , Magnus Hagander , Fujii Masao , PostgreSQL Developers Subject: Re: compute_query_id and pg_stat_statements Message-ID: References: <35457b09-36f8-add3-1d07-6034fa585ca8@oss.nttdata.com> <20210424152220.GL7629@momjian.us> <20210424170908.GM7629@momjian.us> <1709439.1619286231@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.) Christoph