Re: [HACKERS] cache in plpgsql

2004-01-05 Thread Karel Zak
On Fri, Jan 02, 2004 at 12:21:22PM -0500, Tom Lane wrote: > Jan Wieck <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Another little problem is that plpgsql doesn't really have any mechanism > >> for invalidating cached stuff at all; it will leak memory like there's > >> no tomorrow if we star

Re: [HACKERS] cache in plpgsql

2004-01-02 Thread Jan Wieck
Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: But can you tell me how to actually check if a saved SPI plan references that particular catalog object or not? This is certainly doable in principle. recordDependencyOnExpr() contains much of the logic that would be needed -- it would need to

Re: [HACKERS] cache in plpgsql

2004-01-02 Thread Jan Wieck
Tom Lane wrote: Jan Wieck <[EMAIL PROTECTED]> writes: Tom Lane wrote: Another little problem is that plpgsql doesn't really have any mechanism for invalidating cached stuff at all; it will leak memory like there's no tomorrow if we start dropping cached subplans. Everyone seems to look at it as a

Re: [HACKERS] cache in plpgsql

2004-01-02 Thread Tom Lane
Jan Wieck <[EMAIL PROTECTED]> 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

Re: [HACKERS] cache in plpgsql

2004-01-02 Thread Tom Lane
Jan Wieck <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Another little problem is that plpgsql doesn't really have any mechanism >> for invalidating cached stuff at all; it will leak memory like there's >> no tomorrow if we start dropping cached subplans. > Everyone seems to look at it as a PL/

Re: [HACKERS] cache in plpgsql

2004-01-01 Thread Tom Lane
Jan Wieck <[EMAIL PROTECTED]> writes: > But can you tell me how to actually check if a saved SPI plan > references that particular catalog object or not? This is certainly doable in principle. recordDependencyOnExpr() contains much of the logic that would be needed -- it would need to be modified

Re: [HACKERS] cache in plpgsql

2004-01-01 Thread Jan Wieck
ivan wrote: may be postgres can use same way like triggers working, and when relation is droping ( what is equal to delete from pg_class) there could be something like trigger after .. which can waiting for CREATE or DROP command, and then clean-up cache, (for each backend). This could be for exam

Re: [HACKERS] cache in plpgsql

2004-01-01 Thread ivan
may be postgres can use same way like triggers working, and when relation is droping ( what is equal to delete from pg_class) there could be something like trigger after .. which can waiting for CREATE or DROP command, and then clean-up cache, (for each backend). This could be for example same mes

Re: [HACKERS] cache in plpgsql

2003-12-31 Thread Jan Wieck
ivan wrote: but , all in all, do you think that now it is ok ? No, I don't. I just prefer complete solutions over patchwork. Jan On Wed, 31 Dec 2003, Jan Wieck wrote: ivan wrote: > why all backend can not using one cache, which would be always Variable sized shared memory with garbage collection

Re: [HACKERS] cache in plpgsql

2003-12-31 Thread ivan
but , all in all, do you think that now it is ok ? On Wed, 31 Dec 2003, Jan Wieck wrote: > 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 c

Re: [HACKERS] cache in plpgsql

2003-12-31 Thread Jan Wieck
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 sai

Re: [HACKERS] cache in plpgsql

2003-12-31 Thread ivan
why all backend can not using one cache, which would be always 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 ? or ... just turn off cache, because its strange to has possible using drop, create et

Re: [HACKERS] cache in plpgsql

2003-12-31 Thread Jan Wieck
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

[HACKERS] cache in plpgsql

2003-12-30 Thread ivan
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 on