X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 9724DD1BB3D for ; Thu, 21 Aug 2003 07:05:34 -0300 (ADT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 46594-06 for ; Thu, 21 Aug 2003 07:05:26 -0300 (ADT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by svr1.postgresql.org (Postfix) with ESMTP id D5930D1BB46 for ; Thu, 21 Aug 2003 07:05:23 -0300 (ADT) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19pmJg-0004PP-00; Thu, 21 Aug 2003 12:05:16 +0200 Received: from [217.230.192.40] (helo=ecologic.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19pmJf-0000V8-00; Thu, 21 Aug 2003 12:05:15 +0200 Message-ID: <3F44995A.8040308@ecologic.de> Date: Thu, 21 Aug 2003 12:05:14 +0200 From: Dani Oderbolz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephan Szabo , pgsql-sql@postgresql.org Subject: Re: "SELECT IN" Still Broken in 7.4b References: <20030820143116.S17177-100000@megazone.bigpanda.com> In-Reply-To: <20030820143116.S17177-100000@megazone.bigpanda.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/261 X-Sequence-Number: 14877 Stephan Szabo wrote: >On Wed, 20 Aug 2003, Rod Taylor wrote: >... > > >>Is the temp table version any faster? I realize it has a higher limit >>to the number of items you can have in the list. >> >> > >Within the scope of the new hashed IN stuff I believe so in at least some >cases. I have a few million row table of integers where searching for >values IN (~10000 values) takes longer than creating the temp table, >copying into it and doing the in subquery. That's not a particularly >meaningful test case, but sending the psql output to /dev/null gives me: ... > But where do your values come from in the first place? Couldn't you optimize your model so that you don't have to copy around such amounts of data? Regards, Dani