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 8AF21D1B471 for ; Mon, 5 Jan 2004 09:14:00 +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 36746-03 for ; Mon, 5 Jan 2004 05:13:13 -0400 (AST) Received: from ara.zf.jcu.cz (ara.zf.jcu.cz [160.217.161.4]) by svr1.postgresql.org (Postfix) with ESMTP id 0753FD1B46C for ; Mon, 5 Jan 2004 05:13:11 -0400 (AST) Received: by ara.zf.jcu.cz (Postfix, from userid 5770) id 5A8109870; Mon, 5 Jan 2004 10:13:12 +0100 (CET) Date: Mon, 5 Jan 2004 10:13:12 +0100 From: Karel Zak To: Tom Lane Cc: Jan Wieck , ivan , pgsql-hackers@postgresql.org Subject: Re: cache in plpgsql Message-ID: <20040105091311.GC13231@zf.jcu.cz> References: <3FF2C608.3090906@Yahoo.com> <3FF2CFE0.70804@Yahoo.com> <3FF4DC86.1000400@Yahoo.com> <2714.1073013920@sss.pgh.pa.us> <3FF59802.4020607@Yahoo.com> <7004.1073064082@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7004.1073064082@sss.pgh.pa.us> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/83 X-Sequence-Number: 48807 On Fri, Jan 02, 2004 at 12:21:22PM -0500, Tom Lane wrote: > Jan Wieck 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. My original PREPARE/EXECUTE patch contained SPI_saveplan() version that save plan to query cache. I think it's pretty bad idea use for same things more separate solutions. For example see RI stuff (triggeres) -- it's perfect adept for PREPARE/EXECUTE query cache instead the current RI solution that save plans in own hash table. I think we can add support for work with query cache to SPI and use it in more places (RI, PL, etc.), something like SPI_saveplan_bykey(). Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr/