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 E8DF1D1DEF3 for ; Sat, 3 Jan 2004 00:59:18 +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 79625-04 for ; Fri, 2 Jan 2004 20:58:37 -0400 (AST) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by svr1.postgresql.org (Postfix) with SMTP id 55020D1E379 for ; Fri, 2 Jan 2004 20:17:11 -0400 (AST) Received: from unknown (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp016.mail.yahoo.com with SMTP; 2 Jan 2004 20:40:36 -0000 Received: from Yahoo.com (pcp01341166pcs.wilog301.pa.comcast.net [68.80.245.191]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id i02KX5k21016; Fri, 2 Jan 2004 15:33:05 -0500 Message-ID: <3FF5C72E.3030402@Yahoo.com> Date: Fri, 02 Jan 2004 14:31:58 -0500 From: Jan Wieck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: ivan , pgsql-hackers@postgresql.org Subject: Re: cache in plpgsql 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> In-Reply-To: <7004.1073064082@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/20 X-Sequence-Number: 48744 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. Not sure what you mean by that. Is it the execution plan shortcut stuff for simple expressions (you know, the faked econtext to evaluate just a function call) that you want to move into SPI as well? > >> 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. Good point. So you mean to call the SPI functionality to mark plans for recompile at temp object destruction as well. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #