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 F0A4F9FA278;
	Thu, 11 May 2006 15:44:05 -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 52947-03; Thu, 11 May 2006 15:43:55 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from svana.org (svana.org [125.62.94.225])
	by postgresql.org (Postfix) with ESMTP id D510F9FA19B;
	Thu, 11 May 2006 15:43:54 -0300 (ADT)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1FeG8Y-0000za-9o; Fri, 12 May 2006 04:43:46 +1000
Date: Thu, 11 May 2006 20:43:46 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: Greg Stark <gsstark@mit.edu>
Cc: "Jim C. Nasby" <jnasby@pervasive.com>, PFC <lists@peufeu.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org,
	pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Message-ID: <20060511184346.GL30113@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <445F7FF8.6070707@comcast.net>
	<1147110142.32369.7.camel@archimedes>
	<20060508175013.GY99570@pervasive.com>
	<28288.1147111196@sss.pgh.pa.us> <op.s89zl30wcigqcu@apollo13>
	<8764kfz1iq.fsf@stark.xeocode.com> <op.s9alfhjrcigqcu@apollo13>
	<20060510192401.GQ99570@pervasive.com>
	<87irocy3p5.fsf@stark.xeocode.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="8SdtHY/0P4yzaavF"
Content-Disposition: inline
In-Reply-To: <87irocy3p5.fsf@stark.xeocode.com>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200605/297
X-Sequence-Number: 19084


--8SdtHY/0P4yzaavF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 wo=
uld
> 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.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--8SdtHY/0P4yzaavF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEY4XiIB7bNG8LQkwRAln9AKCFgYWudZO1ZVrOW54ROba1LrTW8QCggu9i
vMIXiGMKBbJtscz5s+5n3Tc=
=Sbe8
-----END PGP SIGNATURE-----

--8SdtHY/0P4yzaavF--