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 07703B439FF
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed,  9 Jul 2003 15:56:29 +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 62433-05
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Wed,  9 Jul 2003 12:55:56 -0300 (ADT)
Received: from mail.bgm-gmbh.de (gamma.bgm-hosting.de [217.115.144.90])
	by svr1.postgresql.org (Postfix) with ESMTP id 900AEB439F9
	for <pgsql-sql@postgresql.org>; Wed,  9 Jul 2003 12:55:32 -0300 (ADT)
Received: from bgm-gmbh.de (localhost [127.0.0.1])
	by mail.bgm-gmbh.de (Postfix) with ESMTP
	id 108F6B6416; Wed,  9 Jul 2003 17:55:32 +0200 (CEST)
Received: from [141.40.169.195] (unknown [141.40.169.195])
	by mail.bgm-gmbh.de (Postfix) with ESMTP
	id 21BC7176C0; Wed,  9 Jul 2003 17:55:31 +0200 (CEST)
Subject: Re: max length of sql select statement ?
From: markus brosch <brosch@gmx.de>
To: Rod Taylor <rbt@rbt.ca>
Cc: pgsql-sql@postgresql.org
In-Reply-To: <1057765512.46100.84.camel@jester>
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>
Content-Type: text/plain
Organization: 
Message-Id: <1057765894.1533.40.camel@sam>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 09 Jul 2003 17:51:35 +0200
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200307/105
X-Sequence-Number: 14219

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? 
> 
> Did you index and ANALYZE the temporary table?

No!

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. 

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 ;-)

Cheers, Markus