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 1qJ5wo-0001m4-V5 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 05:30:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qJ5wn-0000Vb-TN for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 05:30:01 +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 1qJ5wn-0000V1-G5 for pgsql-hackers@lists.postgresql.org; Tue, 11 Jul 2023 05:30:01 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qJ5wi-003Poa-Fq for pgsql-hackers@lists.postgresql.org; Tue, 11 Jul 2023 05:30:00 +0000 Received: from [192.168.28.143] (unknown [192.168.28.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id A05E2E20E5C; Tue, 11 Jul 2023 08:29:43 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1689053395; bh=n+5Dxk6+Pw7kKHqfEFBoOEvfVLaDyU6rI4mO+5dW1Fs=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=0Atx7PiCg2MqB8gpxMNvSRyI3j/ESzhB74j5Parz8VDMikD9AYm9kzjL2kv6vpQzP II57KMygplMICj9p4NigsFO98qZAxzyxeCa63YeB2f/Czi6K7Xt6wiX2jobEFvsLd/ ZKmWPoxRPG2Q8T5DtIgTtAjtC9ZobLtsEZ9MIZ6qB49Bw41CIdpYPRWHvUnFtL9a55 phseOZwTSUg3BO2bw1tY6QWTm8O5WqZBymuvVqwYErb609aFys256G2KiNaAc4SokZ I7krFnX3+tFFWLnogtDh+a2Ei4YtZhhl0vk99TyNJ0QAxtU4kWlkbKsgmsxbjfSJoT zM0wnqGNXvLlw== Message-ID: <5bcbf926-3d5a-e953-79a6-b6ab0f8b23a0@postgrespro.ru> Date: Tue, 11 Jul 2023 12:29:29 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Generating code for query jumbling through gen_node_support.pl To: Michael Paquier , Peter Eisentraut Cc: Postgres hackers , "Drouvot, Bertrand" , "Jonathan S. Katz" References: <50b571dc-e0c0-22be-9803-4a3480d2e792@enterprisedb.com> <9695f035-0f2b-92b9-deed-0b7e5bb7e4e0@enterprisedb.com> <268fd337-8bb7-92e6-0da2-416c022c11f3@enterprisedb.com> Content-Language: en-US From: Andrey Lepikhov Organization: Postgres Professional In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 11/7/2023 05:35, Michael Paquier wrote: > On Mon, Jan 30, 2023 at 11:48:45AM +0100, Peter Eisentraut wrote: >> On 27.01.23 03:59, Michael Paquier wrote: >>> At the end, that would be unnoticeable for the average user, I guess, >>> but here are the numbers I get on my laptop :) >> >> Personally, I think we do not want the two jumble methods in parallel. >> >> Maybe there are other opinions. > > (Thanks Jonathan for the poke.) > > Now that we are in mid-beta for 16, it would be a good time to > conclude on this open item: > "Reconsider a utility_query_id GUC to control if query jumbling of > utilities can go through the past string-only mode and the new mode?" > > In Postgres ~15, utility commands used a hash of the query string to > compute their query ID. The current query jumbling code uses a Query > instead, like any other queries. I have registered this open item as > a self-reminder, mostly in case there would be an argument to have a > GUC where users could switch from one mode to another. See here as > well for some computation times for each method (table is in ns, wiht > millions of iterations): > https://www.postgresql.org/message-id/Y9eeYinDb1AcpWrG@paquier.xyz > > I still don't think that we need both methods based on these numbers, > but there may be more opinions about that? Are people OK if this open > item is discarded? I vote for only one method based on a query tree structure. BTW, did you think about different algorithms of queryId generation? Auto-generated queryId code can open a way for extensions to have easy-supporting custom queryIds. -- regards, Andrey Lepikhov Postgres Professional