Re: cache in plpgsql

ivan wrote:
> why all backend can not using one cache, which would be always

Variable sized shared memory with garbage collection for SPI plans?

> in real state ... or i can just clear only my cache, at first
> (if i know that this relation could has another oid)
> and then normal using relations ?

As said, that is not sufficient. The user who does the DDL statement can 
as well reconnect to the database to recompile all saved plans. It is 
the 200 persistent PHP DB connections that suffer from not finding the 
index any more.

> 
> or ... just turn off cache, because its strange to has possible
> using drop, create etc in function, but using only EXECUTE ..

Do you have any numbers about how that would affect performance?


Jan

> 
> there must be same solution .. no ?
> 
> 
> On Wed, 31 Dec 2003, Jan Wieck wrote:
> 
>> ivan wrote:
>>
>> >as new know plpgsql has special cache which remember too long (event
>> >non-existing tables (i mean old oid)) so i suggest to create same function
>> >only in plpgsql which would clear this cache, or sth like this ?
>> >
>> >for ie, where i drop table i would do plpgsql_clear_cache ();
>> >and when i will create one more time table with this same name plpgsql
>> >will not remeber wrong oid
>> >
>> >possible ?
>> >
>> >
>>
>> You obviously did not bother to search the archives on this.
>>
>> This will not solve the problem since the "cache" you're talking about
>> is per backend local memory. So if one backend modifies the schema, how
>> does it cause all other to forgt? Since the same problem exists in
>> general for everything that uses SPI, the solution lies in there.
>>
>>
>> Jan
>>
>> --
>>
>> #======================================================================#
>> # It's easier to get forgiveness for being wrong than for being right. #
>> # Let's break this rule - forgive me.                                  #
>> #================================================== JanWieck@Yahoo.com #
>>
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 3: if posting/reading through Usenet, please send an appropriate
>>       subscribe-nomail command to majordomo@postgresql.org so that your
>>       message can get through to the mailing list cleanly
>>


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #