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 9B1D0D1B44E for ; Wed, 31 Dec 2003 19:38:17 +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 24921-02 for ; Wed, 31 Dec 2003 15:37:28 -0400 (AST) Received: from smtp102.mail.sc5.yahoo.com (smtp102.mail.sc5.yahoo.com [216.136.174.140]) by svr1.postgresql.org (Postfix) with SMTP id 17E70D1B436 for ; Wed, 31 Dec 2003 15:37:27 -0400 (AST) Received: from unknown (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login) by smtp102.mail.sc5.yahoo.com with SMTP; 31 Dec 2003 19:37:27 -0000 Received: from Yahoo.com (ismtp.afilias.com [216.217.55.254]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id hBVJbRk16420; Wed, 31 Dec 2003 14:37:27 -0500 Message-ID: <3FF31726.1050504@Yahoo.com> Date: Wed, 31 Dec 2003 13:36:22 -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: ivan Cc: pgsql-hackers@postgresql.org Subject: Re: cache in plpgsql References: <3FF2C608.3090906@Yahoo.com> <3FF2CFE0.70804@Yahoo.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=2.0 tagged_above=0.0 required=5.0 tests=IN_REP_TO, QUOTED_EMAIL_TEXT, RCVD_FAKE_HELO_DOTCOM_2, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA X-Spam-Level: ** X-Archive-Number: 200312/813 X-Sequence-Number: 48717 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 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 said, that is not sufficient. The user who does the DDL statement can >> as well reconnect to the database to recompile all saved plans. It is >> the 200 persistent PHP DB connections that suffer from not finding the >> index any more. >> >> > >> > or ... just turn off cache, because its strange to has possible >> > using drop, create etc in function, but using only EXECUTE .. >> >> Do you have any numbers about how that would affect performance? >> >> >> Jan >> >> > >> > there must be same solution .. no ? >> > >> > >> > On Wed, 31 Dec 2003, Jan Wieck wrote: >> > >> >> 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 create one more time table with this same name plpgsql >> >> >will not remeber wrong oid >> >> > >> >> >possible ? >> >> > >> >> > >> >> >> >> You obviously did not bother to search the archives on this. >> >> >> >> This will not solve the problem since the "cache" you're talking about >> >> is per backend local memory. So if one backend modifies the schema, how >> >> does it cause all other to forgt? Since the same problem exists in >> >> general for everything that uses SPI, the solution lies in there. >> >> >> >> >> >> Jan >> >> >> >> -- >> >> >> >> #======================================================================# >> >> # It's easier to get forgiveness for being wrong than for being right. # >> >> # Let's break this rule - forgive me. # >> >> #================================================== JanWieck@Yahoo.com # >> >> >> >> >> >> >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> >> TIP 3: if posting/reading through Usenet, please send an appropriate >> >> subscribe-nomail command to majordomo@postgresql.org so that your >> >> message can get through to the mailing list cleanly >> >> >> >> >> -- >> #======================================================================# >> # It's easier to get forgiveness for being wrong than for being right. # >> # Let's break this rule - forgive me. # >> #================================================== JanWieck@Yahoo.com # >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: don't forget to increase your free space map settings >> -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #