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
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 |