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 1lb5Gq-0001vU-KV for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Apr 2021 17:43:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lb5Gp-0006yC-6B for pgsql-hackers@arkaria.postgresql.org; Mon, 26 Apr 2021 17:43:43 +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 1lb5Go-0006Qn-3n for pgsql-hackers@lists.postgresql.org; Mon, 26 Apr 2021 17:43:42 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lb5Gk-0002uz-LW for pgsql-hackers@lists.postgresql.org; Mon, 26 Apr 2021 17:43:41 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 45F8B194F; Mon, 26 Apr 2021 13:43:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 26 Apr 2021 13:43:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=n7a/C3j7i2CyzUTh7mLCUzfHGAqNGBVrainlRFNJEZo=; b=AAfDvsUo rRMdSJAqP3CLzYDrL30b9RzK/lPqzM1t8LMxJiNZ7O6iMzXDQPlx9gOYljiX0GDT /466DZICa2jLt5FKRNB3QNL6kgMcGPA+ZKKijvvSLQ4FabHNUa4QMxPeqzP2pb/K nMohqe8aN0hD7rN24je0vy7jrcZL4AnYKIKN6lT8qO1f8WzO9Vzt9rsUMs90TKxa KE4FnbKUcXP0vTvcImctFMEUulj4I8//s0RBb/yA/sLD+OHihwJr2/+Np7D+glCp 1IGmnKkaas0s4hxbmoxY3GfgI3TlTQsopKVymaFJckdWd47QEsLWFZjYnKQHembm 0txanalH8UK3VA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddukedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjggfsehtkeertddtredunecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpeeufffhjeeiueeuffegvddukeegledtveeivdeiueef ieeivefgteehueefteehvdenucfkphepudeltddrleehrdduledrleehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegr lhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id A9E58108005C; Mon, 26 Apr 2021 13:43:34 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id D4BE32A0ADE; Mon, 26 Apr 2021 13:43:31 -0400 (-04) Date: Mon, 26 Apr 2021 13:43:31 -0400 From: Alvaro Herrera To: Tom Lane Cc: Stephen Frost , Magnus Hagander , Bruce Momjian , Christoph Berg , Peter Eisentraut , Fujii Masao , PostgreSQL Developers Subject: Re: compute_query_id and pg_stat_statements Message-ID: <20210426174331.GA19401@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2268611.1619458140@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Apr-26, Tom Lane wrote: > Stephen Frost writes: > > * Magnus Hagander (magnus@hagander.net) wrote: > >> Thatäs why I suggested the three value one. Default to a mode where > >> it's automatic, which is what the majority is going to want, but have > >> a way to explicitly turn it on. > > > This is certainly fine with me too, though it seems a bit surprising to > > me that we couldn't just figure out what the user actually wants based > > on what's installed/running for any given combination. > > I'd be on board with having pg_stat_statement's pg_init function do > something to adjust the setting, if we can figure out how to do that > in a way that's not confusing in itself. I'm not sure though that > the GUC engine offers a good way. I think it's straightforward, if we decouple the tri-valued enum used for guc.c purposes from a separate boolean that actually enables the feature. GUC sets the boolean to "off" initially when it sees the enum as "auto", and then pg_stat_statement's _PG_init modifies it during its own startup as needed. So the user can turn the GUC off, and then pg_stat_statement does nothing and there is no performance drawback; or leave it "auto" and it'll only compute query_id if pg_stat_statement is loaded; or leave it on if they want the query_id for other purposes. -- Álvaro Herrera 39°49'30"S 73°17'W "El miedo atento y previsor es la madre de la seguridad" (E. Burke)