X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id AB140D1B987 for ; Fri, 22 Aug 2003 12:29:25 -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 72620-03 for ; Fri, 22 Aug 2003 12:29:00 -0300 (ADT) Received: from smtp.istop.com (dci.doncaster.on.ca [66.11.168.194]) by svr1.postgresql.org (Postfix) with ESMTP id 850B7D1B8BF for ; Fri, 22 Aug 2003 12:28:54 -0300 (ADT) Received: from stark.dyndns.tv (gsstark.mtl.istop.com [66.11.160.162]) by smtp.istop.com (Postfix) with ESMTP id B38C73694F; Fri, 22 Aug 2003 11:28:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 19qDqR-0004Kg-00; Fri, 22 Aug 2003 11:28:55 -0400 To: pgsql-hackers@postgresql.org Subject: Re: [SQL] "SELECT IN" Still Broken in 7.4b References: <20030821102627.C51705-100000@megazone.bigpanda.com> <25062.1061498540@sss.pgh.pa.us> <28348.1061502363@sss.pgh.pa.us> In-Reply-To: <28348.1061502363@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 22 Aug 2003 11:28:55 -0400 Message-ID: <87k795iudk.fsf@stark.dyndns.tv> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200308/988 X-Sequence-Number: 42645 Tom Lane writes: > Finally, I suspect that once we get rid of the O(N^2) behavior in the > executor, we will find that the next biggest bottleneck is in the > planner; adding more work for it to do per OR-clause item will make > things worse not better. But time spent in the planner doesn't matter if you're using prepared queries which is true for OLTP applications where there are very few queries being executed many many times. I hear web sites are quite popular these days. I missed the beginning of this thread so I'm not sure if it's relevant. But wouldn't it be possible to just check if all the clauses and see if they're using precisely the same index with an equality type operator? That won't catch things like "a BETWEEN 1 AND 2 OR a BETWEEN 5 AND 6" but it will catch things like "a IN (1,2,3,4,5,6)". And I don't see how it wouldn't be linear in the number of clauses. -- greg