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 1ltykW-0001E6-Km for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jun 2021 20:36:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ltykV-0008Uy-Io for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Jun 2021 20:36:27 +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 1ltykV-0008Ul-BO for pgsql-hackers@lists.postgresql.org; Thu, 17 Jun 2021 20:36:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ltykT-0006fz-Cp for pgsql-hackers@lists.postgresql.org; Thu, 17 Jun 2021 20:36:26 +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 15HKaMil1057944; Thu, 17 Jun 2021 16:36:22 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@lists.postgresql.org Subject: Re: Centralizing protective copying of utility statements In-reply-to: <20210617192300.7gkpqim43gk7ernd@alap3.anarazel.de> References: <931771.1623893989@sss.pgh.pa.us> <20210617192300.7gkpqim43gk7ernd@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Thu, 17 Jun 2021 12:23:00 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1057942.1623962182.1@sss.pgh.pa.us> Date: Thu, 17 Jun 2021 16:36:22 -0400 Message-ID: <1057943.1623962182@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2021-06-16 21:39:49 -0400, Tom Lane wrote: >> Although this adds some overhead in the form of copying of >> utility node trees that won't actually mutate during execution, >> I think that won't be too bad because those trees tend to be >> small and hence cheap to copy. > Have you evaluated the cost in some form? I don't think it a relevant > cost for most utility statements, but there's a few exceptions that *do* > worry me. In particular, in some workloads transaction statements are > very frequent. I hadn't, but since you mention it, I tried this test case: $ cat trivial.sql begin; commit; $ pgbench -n -M prepared -f trivial.sql -T 60 I got these results on HEAD: tps = 23853.244130 (without initial connection time) tps = 23810.759969 (without initial connection time) tps = 23167.608493 (without initial connection time) tps = 23784.432746 (without initial connection time) and adding the v2 patch: tps = 23298.081147 (without initial connection time) tps = 23614.466755 (without initial connection time) tps = 23475.297853 (without initial connection time) tps = 23530.826527 (without initial connection time) So if you squint there might be a sub-one-percent difference there, but it's barely distinguishable from the noise. In any situation where the transactions are doing actual work, I doubt you could measure a difference. (In any case, if someone does get excited about this, they could rearrange things to push the copyObject calls into the individual arms of the switch in ProcessUtility. Personally though I doubt it could be worth the code bloat.) regards, tom lane