X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (developer.postgresql.org [64.117.224.193])
	by svr1.postgresql.org (Postfix) with ESMTP id 60056B430BF
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed,  9 Jul 2003 17:02:24 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
	by localhost (svr1.postgresql.org [64.117.224.193]) (amavisd-new,
	port 10024) with ESMTP id 88921-07
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed,  9 Jul 2003 14:01:51 -0300 (ADT)
Received: from mailav.tor1.inquent.com (mail.inquent.com [216.208.117.106])
	by svr1.postgresql.org (Postfix) with ESMTP id D9754B4241A
	for <pgsql-sql@postgresql.org>; Wed,  9 Jul 2003 14:01:50 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
	by mailav.tor1.inquent.com (Postfix) with ESMTP
	id 9042310257; Wed,  9 Jul 2003 12:55:07 -0400 (EDT)
Received: from [10.0.2.7] (unknown [10.0.2.7])
	by mailav.tor1.inquent.com (Postfix) with ESMTP
	id AE0351024D; Wed,  9 Jul 2003 12:55:05 -0400 (EDT)
Subject: Re: max length of sql select statement ?
From: Rod Taylor <rbt@rbt.ca>
To: markus brosch <brosch@gmx.de>
Cc: pgsql-sql@postgresql.org
In-Reply-To: <1057765894.1533.40.camel@sam>
References: <1057592658.881.93.camel@sam>
	<1101.219.65.226.199.1057593454.squirrel@mail.trade-india.com>
	<1057594050.886.104.camel@sam>  <1057594852.46100.11.camel@jester>
	<1057743944.15655.12.camel@sam>  <1057757398.46100.63.camel@jester>
	<1057764847.863.34.camel@sam>  <1057765512.46100.84.camel@jester>
	<1057765894.1533.40.camel@sam>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-zxtISdMiokaq+4IU6utB"
Message-Id: <1057770139.46100.93.camel@jester>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.0 
Date: 09 Jul 2003 17:02:20 +0000
X-Virus-Scanned: by AMaViS perl-11
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200307/106
X-Sequence-Number: 14220

--=-zxtISdMiokaq+4IU6utB
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-07-09 at 15:51, markus brosch wrote:
> On Wed, 2003-07-09 at 17:45, Rod Taylor wrote:
> > > Nobody a better idea? Why is the join of a temporary table (the IN
> > > paramters) and the original table so slow? Any tricks here?=20
> >=20
> > Did you index and ANALYZE the temporary table?
>=20
> No!
>=20
> I have to do this "strange" and "long" statement also a view thousand
> times ... so I always have to create the temp table again and again and
> if I index the table it costs me more time.=20

So.. which costs more.  Building the index + fast query or doing the
slow query?

If you have anything more than a thousand lines in the temp table, I bet
indexing it would be the better way to go.

> As far I am relativly new to SQL, I ask you:
> Where's the difference between and indexed temp (!!!) table and an
> unindexed one? The main table is of course fully indexed ;-)

One has an index, which means that other (much faster) methods may be
available for the database to use.

--=-zxtISdMiokaq+4IU6utB
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQA/DEqa6DETLow6vwwRAiPrAJwOG7uvKjlMwAbf2BlrgN7RM48MlACbBoYO
TB3Rp6C41Mb83DXBtw2u5Mo=
=6zXm
-----END PGP SIGNATURE-----

--=-zxtISdMiokaq+4IU6utB--