X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 5D7A39FA2C3; Thu, 11 May 2006 17:00:38 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 66976-03; Thu, 11 May 2006 17:00:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 7AE489FA278; Thu, 11 May 2006 17:00:31 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 837EB56427; Thu, 11 May 2006 15:00:30 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Thu, 11 May 2006 15:00:28 -0500 Date: Thu, 11 May 2006 15:00:28 -0500 From: "Jim C. Nasby" To: Martijn van Oosterhout Cc: Greg Stark , PFC , Tom Lane , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal Message-ID: <20060511200028.GM99570@pervasive.com> References: <445F7FF8.6070707@comcast.net> <1147110142.32369.7.camel@archimedes> <20060508175013.GY99570@pervasive.com> <28288.1147111196@sss.pgh.pa.us> <8764kfz1iq.fsf@stark.xeocode.com> <20060510192401.GQ99570@pervasive.com> <87irocy3p5.fsf@stark.xeocode.com> <20060511184346.GL30113@svana.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060511184346.GL30113@svana.org> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060511:kleptog@svana.org::3UmfheADOTPsgb8q:00000000000000000000 0000000000000000000000002aUq X-Hashcash: 1:20:060511:gsstark@mit.edu::l5wqSpBcawkzwBV6:0002N5 X-Hashcash: 1:20:060511:lists@peufeu.com::TZtNRd5Iqh/BtVHD:01I/w X-Hashcash: 1:20:060511:tgl@sss.pgh.pa.us::GPcwWcvLdOoD/NfY:00000000000000000000 0000000000000000000000009jRL X-Hashcash: 1:20:060511:pgsql-performance@postgresql.org::ehhLFh4Etkst5z/p:00000 0000000000000000000000000WXU X-Hashcash: 1:20:060511:pgsql-hackers@postgresql.org::H+H4YZ7a/16rPWXp:000000000 000000000000000000000000Dzqe X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/299 X-Sequence-Number: 19086 On Thu, May 11, 2006 at 08:43:46PM +0200, Martijn van Oosterhout wrote: > On Thu, May 11, 2006 at 11:35:34AM -0400, Greg Stark wrote: > > I can say that I've seen plenty of instances where the ability to create > > temporary tables very quickly with no overhead over the original query would > > be useful. > > I wonder if this requires what the standard refers to as a global > temporary table. As I read it (which may be wrong, I find the language > obtuse), a global temporary table is a temporary table whose structure > is predefined. So, you'd define it once, updating the catalog only once > but still get a table that is emptied each startup. > > Ofcourse, it may not be what the standard means, but it still seems > like a useful idea, to cut down on schema bloat. IIRC that's the exact syntax Oracle uses: CREATE GLOBAL TEMPORARY TABLE ... I always found it a bit odd, since it always seemed to me like a global temporary table would be one that every backend could read... something akin to a real table that doesn't worry about fsync or any of that (and is potentially not backed on disk at all). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461