Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jHT5h-0004wj-Hb for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2020 14:02:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jHT5g-0000wG-7F for pgsql-hackers@arkaria.postgresql.org; Thu, 26 Mar 2020 14:02:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jHT5f-0000vu-Ui for pgsql-hackers@lists.postgresql.org; Thu, 26 Mar 2020 14:02:35 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jHT5Z-0007Z7-G6 for pgsql-hackers@postgresql.org; Thu, 26 Mar 2020 14:02:35 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 02QE2Kw7011119; Thu, 26 Mar 2020 10:02:20 -0400 From: Tom Lane To: Andres Freund cc: Pavel Stehule , Amit Langote , PostgreSQL Hackers Subject: Re: plan cache overhead on plpgsql expression In-reply-to: <20200325224903.pwsx4pccyktq7tx6@alap3.anarazel.de> References: <1478.1584815045@sss.pgh.pa.us> <20200325211825.gf2ta424kwkfghbr@alap3.anarazel.de> <15634.1585173110@sss.pgh.pa.us> <20200325224903.pwsx4pccyktq7tx6@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 25 Mar 2020 15:49:03 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11117.1585231340.1@sss.pgh.pa.us> Date: Thu, 26 Mar 2020 10:02:20 -0400 Message-ID: <11118.1585231340@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > On 2020-03-25 17:51:50 -0400, Tom Lane wrote: >> Andres Freund writes: >>> Hm, any chance that the multiple resowner calls here could show up in a >>> profile? Probably not? >> Doubt it. On the other hand, as the code stands it's certain that the >> resowner contains nothing but plancache pins (while I was writing the >> patch it wasn't entirely clear that that would hold). So we could >> drop the two unnecessary calls. There are assertions in >> ResourceOwnerDelete that would fire if we somehow missed releasing >> anything, so it doesn't seem like much of a maintenance hazard. > One could even argue that that's a nice crosscheck: Due to the later > release it'd not actually be correct to just add "arbitrary" things to > that resowner. I had a thought about a possibly-cleaner way to do this. We could invent a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that explicitly releases all plancache pins it knows about. So plpgsql would not call the regular ResourceOwnerRelease entry point at all, but just call that and then ResourceOwnerDelete, again relying on the assertions therein to catch anything not released. This would be slightly more code but it'd perhaps make it clearer what's going on, without the cost of a duplicative data structure. Perhaps in future there'd be use for similar calls for other resource types. regards, tom lane