Re: cache in plpgsql

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: ivan <iv(at)psycho(dot)pl>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: cache in plpgsql
Date: 2003-12-31 13:32:16
Message-ID: 3FF2CFE0.70804@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)Yahoo(dot)com #
>>
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 3: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo(at)postgresql(dot)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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Iavor Raytchev 2003-12-31 14:22:57 Uninstalling Mammoth
Previous Message ivan 2003-12-31 13:26:25 Happy New Year ! :) and about gethostbyaddr