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 1lgLyW-000242-Og for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 06:34:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lgLyU-0002bJ-Uj for pgsql-hackers@arkaria.postgresql.org; Tue, 11 May 2021 06:34:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lgLyU-0002bA-Mz for pgsql-hackers@lists.postgresql.org; Tue, 11 May 2021 06:34:34 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lgLyP-0001lh-4G for pgsql-hackers@lists.postgresql.org; Tue, 11 May 2021 06:34:33 +0000 Received: from hnk.local (p2388012-ipbf1027funabasi.chiba.ocn.ne.jp [118.6.6.12]) by oss.nttdata.com (Postfix) with ESMTPSA id 097CF6056E; Tue, 11 May 2021 15:34:19 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.2 at oss.nttdata.com Subject: Re: compute_query_id and pg_stat_statements To: Michael Paquier , Julien Rouhaud Cc: Andres Freund , Tom Lane , Alvaro Herrera , Stephen Frost , Magnus Hagander , Bruce Momjian , Christoph Berg , Peter Eisentraut , PostgreSQL Developers References: <2268611.1619458140@sss.pgh.pa.us> <20210426174331.GA19401@alvherre.pgsql> <20210426181408.3j6kkzpxnadpwptv@alap3.anarazel.de> <2295572.1619461260@sss.pgh.pa.us> <20210426183745.4gd2s5qra6mlxfto@alap3.anarazel.de> <20210427062504.ofz3rgedbrl5bep2@nol> From: Fujii Masao Message-ID: <154cacc0-9aa9-a37b-0a0f-17aa08ff706e@oss.nttdata.com> Date: Tue, 11 May 2021 15:34:18 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021/05/11 15:04, Michael Paquier wrote: > On Tue, Apr 27, 2021 at 02:25:04PM +0800, Julien Rouhaud wrote: >> On Mon, Apr 26, 2021 at 11:37:45AM -0700, Andres Freund wrote: >>> On 2021-04-26 14:21:00 -0400, Tom Lane wrote: >>>> That's sounding like a pretty sane design, actually. Not sure about >>>> the shared-library-name-with-fixed-function-name detail, but certainly >>>> it seems to be useful to separate "I need a query-id" from the details >>>> of the ID calculation. >>>> >>>> Rather than a GUC per se for the ID provider, maybe we could have a >>>> function hook that defaults to pointing at the in-core computation, >>>> and then a module wanting to override that just gets into the hook. >>> >>> I have a preference to determining the provider via GUC instead of a >>> hook because it is both easier to introspect and easier to configure. > > So, this thread has died two weeks ago, and it is still an open item. > Could it be possible to move to a resolution by beta1? The consensus > I can get from the thread is that we should have a tri-value state to > track an extra "auto" for the query ID computation, as proposed by > Alvaro here: > https://www.postgresql.org/message-id/20210426174331.GA19401@alvherre.pgsql +1 Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION