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 1mHVYn-0007wO-Gx for pgsql-performance@arkaria.postgresql.org; Sat, 21 Aug 2021 18:17:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mHVYm-0005ei-7M for pgsql-performance@arkaria.postgresql.org; Sat, 21 Aug 2021 18:17:36 +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 1mHVYl-0005ea-VO for pgsql-performance@lists.postgresql.org; Sat, 21 Aug 2021 18:17:35 +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 1mHVYg-0002Fw-Tt for pgsql-performance@postgresql.org; Sat, 21 Aug 2021 18:17:35 +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 17LIHQ4f2136208; Sat, 21 Aug 2021 14:17:26 -0400 From: Tom Lane To: "ldh@laurent-hasson.com" cc: "pgsql-performance@postgresql.org" Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4 In-reply-to: References: <2092859.1629558281@sss.pgh.pa.us> Comments: In-reply-to "ldh@laurent-hasson.com" message dated "Sat, 21 Aug 2021 16:01:16 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2136206.1629569846.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2021 14:17:26 -0400 Message-ID: <2136207.1629569846@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "ldh@laurent-hasson.com" writes: > So you mean that on average, the 4x overhead of exceptions is around wha= t you'd expect? Doesn't surprise me any, no. Exception recovery has to clean up after a wide variety of possible errors, with only minimal assumptions about what the system state had been. So it's expensive. More to the point, the overhead's been broadly the same for quite some time. > As for results in general, yes, your numbers look pretty uniform across = versions. On my end, comparing V11.2 vs V13.4 shows a much different pictu= re! I'm baffled why that should be so. I do not think any of the extensions you mention add any exception-recovery overhead, especially not in sessions that haven't used them. As an additional test, I checked out 11.2 exactly, and got timings that pretty much matched my previous test of v11 branch tip. So that eliminates the theory that we broke something since 11.2 in a patch that was also back-patched into that branch. regards, tom lane