X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (neptune.hub.org [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP id 7E36ED1DC07
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Fri,  2 Jan 2004 22:28:33 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 65516-01
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Fri,  2 Jan 2004 18:27:49 -0400 (AST)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by svr1.postgresql.org (Postfix) with ESMTP id 45D60D1DCA4
	for <pgsql-hackers@postgresql.org>;
	Fri,  2 Jan 2004 18:15:49 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.10/8.12.10) with ESMTP id i02HLM19007005;
	Fri, 2 Jan 2004 12:21:22 -0500 (EST)
To: Jan Wieck <JanWieck@Yahoo.com>
Cc: ivan <iv@psycho.pl>, pgsql-hackers@postgresql.org
Subject: Re: cache in plpgsql 
In-reply-to: <3FF59802.4020607@Yahoo.com> 
References: <Pine.LNX.4.56.0312302329590.5131@rex.anfa.pl>
	<3FF2C608.3090906@Yahoo.com>
	<Pine.LNX.4.56.0312311417500.20780@rex.anfa.pl>
	<3FF2CFE0.70804@Yahoo.com>
	<Pine.LNX.4.56.0401011655420.13912@rex.anfa.pl>
	<3FF4DC86.1000400@Yahoo.com> <2714.1073013920@sss.pgh.pa.us>
	<3FF59802.4020607@Yahoo.com>
Comments: In-reply-to Jan Wieck <JanWieck@Yahoo.com>
	message dated "Fri, 02 Jan 2004 11:10:42 -0500"
Date: Fri, 02 Jan 2004 12:21:22 -0500
Message-ID: <7004.1073064082@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200401/18
X-Sequence-Number: 48742

Jan Wieck <JanWieck@Yahoo.com> 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/pgSQL specific problem. It is not!

No, of course not, but plpgsql has issues of its own that (IMHO) should
be solved along with the SPI-level problem.

> As said, the idea is neither bad, nor new. And please let's not forget 
> to add temp object detection into the dependency collector so that SPI 
> automagically will handle temp tables used in PL/pgSQL by NOT storing 
> prepared plans at all.

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.

			regards, tom lane