Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id CF3909FB5A5; Fri, 12 Jan 2007 08:44:05 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 15850-06; Fri, 12 Jan 2007 08:43:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from stark.xeocode.com (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id 97EE09FB59F; Fri, 12 Jan 2007 08:43:52 -0400 (AST) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with esmtp (Exim 4.63) (envelope-from ) id 1H5Ll1-00058n-Ak; Fri, 12 Jan 2007 12:43:43 +0000 From: Gregory Stark To: "Tom Lane" Cc: "Alvaro Herrera" , "Simon Riggs" , "Kim" , , Subject: Re: [PERFORM] unusual performance for vac following 8.2upgrade In-Reply-To: <29730.1168570299@sss.pgh.pa.us> (Tom Lane's message of "Thu, 11 Jan 2007 21:51:39 -0500") Organization: EnterpriseDB References: <45A671CD.1050706@myemma.com> <27939.1168539652@sss.pgh.pa.us> <45A68C74.4080405@myemma.com> <28949.1168544710@sss.pgh.pa.us> <1168548006.3951.564.camel@silverbirch.site> <5414.1168549900@sss.pgh.pa.us> <1168557275.3990.49.camel@silverbirch.site> <20070112010918.GM10464@alvh.no-ip.org> <29730.1168570299@sss.pgh.pa.us> X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 4911) Date: Fri, 12 Jan 2007 12:43:42 +0000 Message-ID: <874pqwwh35.fsf@stark.xeocode.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/623 X-Sequence-Number: 96524 "Tom Lane" writes: > 3. What about dependencies on user-defined types, functions, etc? > How will you get things to behave sanely if one backend tries to drop a > type that some other backend is using in a column of a temp table? Even > if you put entries into pg_depend, which would kind of defeat the point > of not having on-disk catalog entries for temp tables, I don't see how > the other backend figures out what the referencing object is. We could just lock the object it depends on. Only really makes sense for very temporary tables though, not tables a session expects to use for a long series of transactions. Another direction to go to address the same problem would be to implement the standard temporary table concept of a permanent table definition for which each session gets a different actual set of data which is reset frequently. Then the meta-data isn't changing frequently. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com