pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: plan cache overhead on plpgsql expression
Date: Thu, 26 Mar 2020 10:02:20 -0400
Message-ID: <11118.1585231340@sss.pgh.pa.us> (raw)
In-Reply-To: <20200325224903.pwsx4pccyktq7tx6@alap3.anarazel.de>
References: <CA+HiwqHOnO4+TriKOF021To3018j5pXAO_ySgi1rqt7MfMtu5w@mail.gmail.com>
	<CAFj8pRAgX-cTRfNcpZEPutOLbVJji10J2L1fAzCbkFxmN_w=LA@mail.gmail.com>
	<CAFj8pRD8JtW71hpcQfOD6kguQut51qHPX3bVZXXZtC7=VB0Cbg@mail.gmail.com>
	<CA+HiwqHuEmzTnYZaJp8D14VCc127dnAKdAWZoV-b6U7oO_oOJg@mail.gmail.com>
	<CA+HiwqEFt+cJUi=DLxmynYwFwWrC3mQMUSMcYefxU-5jgaeWew@mail.gmail.com>
	<CAFj8pRBVeseNF+jDaZOrC0-W540Mx-DAEvELMeveJs10L9i=Rg@mail.gmail.com>
	<CAFj8pRBH2T=7VoTrY7hf5MNUWE45zZpdWWvv+hzEem=Wn3GcNg@mail.gmail.com>
	<1478.1584815045@sss.pgh.pa.us>
	<20200325211825.gf2ta424kwkfghbr@alap3.anarazel.de>
	<15634.1585173110@sss.pgh.pa.us>
	<20200325224903.pwsx4pccyktq7tx6@alap3.anarazel.de>

Andres Freund <andres@anarazel.de> writes:
> On 2020-03-25 17:51:50 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> 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





view thread (41+ messages)  latest in thread

Message-ID: <11118.1585231340@sss.pgh.pa.us>
Permalink:  ../11118.1585231340@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/11118.1585231340@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pavel.stehule@gmail.com, amitlangote09@gmail.com
  Subject: Re: plan cache overhead on plpgsql expression
  In-Reply-To: <11118.1585231340@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox