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 6A9DDD1D302 for ; Fri, 2 Jan 2004 22:28:25 +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 64321-08 for ; Fri, 2 Jan 2004 18:27:42 -0400 (AST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 29CBCD1D37A for ; Fri, 2 Jan 2004 18:15:45 -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 i02KjM19014938; Fri, 2 Jan 2004 15:45:22 -0500 (EST) To: Jan Wieck Cc: ivan , pgsql-hackers@postgresql.org Subject: Re: cache in plpgsql In-reply-to: <3FF5C72E.3030402@Yahoo.com> 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> <3FF5C72E.3030402@Yahoo.com> Comments: In-reply-to Jan Wieck message dated "Fri, 02 Jan 2004 14:31:58 -0500" Date: Fri, 02 Jan 2004 15:45:21 -0500 Message-ID: <14937.1073076321@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200401/17 X-Sequence-Number: 48741 Jan Wieck 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 malloc and cannot be effectively reclaimed when the function definition is invalidated. I'd also like to get rid of its ad-hoc method of detecting function definition changes (viz, looking at the pg_proc row's xmin) in favor of hooking it into the same cache invalidation mechanism as SPI would be using. These are perhaps not essential changes, but they should happen eventually. >> 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. I think it would be difficult to avoid. Temp objects are not very magic in themselves, they just live in particular schemas that happen to be a little bit magic. regards, tom lane