Re: cache in plpgsql

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: ivan <iv(at)psycho(dot)pl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: cache in plpgsql
Date: 2004-01-02 20:45:21
Message-ID: 14937.1073076321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Tom Lane wrote:
>> No, of course not, but plpgsql has issues of its own that (IMHO) should
>> be solved along with the SPI-level problem.

> Not sure what you mean by that.

I'm referring to the fact that plpgsql's internal data structures are
all built with malloc and cannot be effectively reclaimed when the
function definition is invalidated. I'd also like to get rid of its
ad-hoc method of detecting function definition changes (viz, looking
at the pg_proc row's xmin) in favor of hooking it into the same cache
invalidation mechanism as SPI would be using.

These are perhaps not essential changes, but they should happen
eventually.

>> Why shouldn't we cache plans for temp tables? They are good as long as
>> the temp table exists. AFAICS the same dependency mechanism will work
>> fine for temp and regular tables.

> Good point. So you mean to call the SPI functionality to mark plans for
> recompile at temp object destruction as well.

I think it would be difficult to avoid. Temp objects are not very magic
in themselves, they just live in particular schemas that happen to be a
little bit magic.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-01-02 21:54:29 Re: Postgres + Xapian (was Re: fulltext searching via a custom index type )
Previous Message Jan Wieck 2004-01-02 19:31:58 Re: cache in plpgsql