Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1so7am-008S4v-QZ for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 20:36:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1so7am-001wXi-BC for pgsql-hackers@arkaria.postgresql.org; Tue, 10 Sep 2024 20:36:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1so7am-001wXa-1z for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2024 20:36:04 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1so7aj-000WN0-9o for pgsql-hackers@lists.postgresql.org; Tue, 10 Sep 2024 20:36:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 48AKa0YF3657866; Tue, 10 Sep 2024 16:36:00 -0400 From: Tom Lane To: David Rowley cc: pgsql-hackers@lists.postgresql.org Subject: Re: Speeding up ruleutils' name de-duplication code, redux In-reply-to: References: <2885468.1722291250@sss.pgh.pa.us> <3472644.1725980806@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Wed, 11 Sep 2024 08:33:59 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3657864.1726000560.1@sss.pgh.pa.us> Date: Tue, 10 Sep 2024 16:36:00 -0400 Message-ID: <3657865.1726000560@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Wed, 11 Sept 2024 at 03:06, Tom Lane wrote: >> We could accomplish what you suggest by re-ordering the calls so that >> we build the hash table before enlarging the array. 0001 attached >> is the same as before (modulo line number changes from being rebased >> up to HEAD) and then 0002 implements this idea on top. On the whole >> though I find 0002 fairly ugly and would prefer to stick to 0001. >> I really doubt that scanning any newly-created column positions is >> going to take long enough to justify intertwining things like this. > I'm fine with that. I did test the performance with and without > v2-0002 and the performance is just a little too noisy to tell. Both > runs I did with v2-0002, it was slower, so I agree it's not worth > making the code uglier for. > I've no more comments. Looks good. Thanks for the review! I'll go push just 0001. regards, tom lane