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 6E29D9F946D;
	Tue,  9 May 2006 07:36:54 -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 38231-06; Tue,  9 May 2006 07:36:49 -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 A38AD9F931D;
	Tue,  9 May 2006 07:36:48 -0300 (ADT)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1FdPZw-00008r-RX; Tue, 09 May 2006 20:36:32 +1000
Date: Tue, 9 May 2006 12:36:32 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: PFC <lists@peufeu.com>
Cc: Christian Kratzer <ck@cksoft.de>, pgsql-performance@postgresql.org,
	pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal
Message-ID: <20060509103632.GD29652@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>
	<20060509105214.P90693@vesihiisi.cksoft.de>
	<op.s8916gm6cigqcu@apollo13>
	<20060509113337.M90693@vesihiisi.cksoft.de>
	<op.s893vzcpcigqcu@apollo13>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="48TaNjbzBVislYPb"
Content-Disposition: inline
In-Reply-To: <op.s893vzcpcigqcu@apollo13>
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/174
X-Sequence-Number: 18961


--48TaNjbzBVislYPb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 09, 2006 at 12:10:37PM +0200, PFC wrote:
> 	Yes, but in this case temp tables add too much overhead. I wish=20
> 	there  were RAM based temp tables like in mysql. However I guess the=20
> current temp  table slowness comes from the need to mark their existence =
in=20
> the system  catalogs or something. That's why I proposed using cursors...

It would be interesting to know what the bottleneck is for temp tables
for you. They do not go via the buffer-cache, they are stored in
private memory in the backend, they are not xlogged. Nor flushed to
disk on backend exit. They're about as close to in-memory tables as
you're going to get...

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.

--48TaNjbzBVislYPb
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)

iD8DBQFEYHCwIB7bNG8LQkwRAlfXAJ9Pr52bigcvr80B5OTOFQDp6FD81gCdETQx
dZs8O2BlYDBo/WTEfO3LwWU=
=ZdNA
-----END PGP SIGNATURE-----

--48TaNjbzBVislYPb--