Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 58E169FB33A for ; Fri, 9 Feb 2007 01:21:00 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 78848-09 for ; Fri, 9 Feb 2007 01:20:47 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by postgresql.org (Postfix) with ESMTP id 2BA9D9FB311 for ; Fri, 9 Feb 2007 01:02:08 -0400 (AST) Received: from [192.168.7.5] ([71.101.65.69]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JD600EGSJAOQ6UE@vms046.mailsrvcs.net> for pgsql-sql@postgresql.org; Thu, 08 Feb 2007 23:01:37 -0600 (CST) Date: Fri, 09 Feb 2007 00:01:59 -0500 From: Joe Subject: Re: huge disparities in =/IN/BETWEEN performance In-reply-to: <14627.1170995084@sss.pgh.pa.us> To: Tom Lane Cc: Alvaro Herrera , George Pavlov , pgsql-sql@postgresql.org Message-id: <1170997319.697.72.camel@pampa> Organization: Freedom Circle, LLC MIME-version: 1.0 X-Mailer: Evolution 2.8.3 FreeBSD GNOME Team Port Content-type: text/plain Content-transfer-encoding: 7bit References: <8C5B026B51B6854CBE88121DBF097A86815F42@ehost010-33.exch010.intermedia.net> <7377.1170986068@sss.pgh.pa.us> <8C5B026B51B6854CBE88121DBF097A86815F81@ehost010-33.exch010.intermedia.net> <20070209021414.GU24069@alvh.no-ip.org> <14273.1170993005@sss.pgh.pa.us> <1170994335.697.55.camel@pampa> <14627.1170995084@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/116 X-Sequence-Number: 27450 Hi Tom, On Thu, 2007-02-08 at 23:24 -0500, Tom Lane wrote: > Certainly, but your other concerns don't follow from that. The issue at > hand here is whether it's worth expending cycles on every query to try > to detect a situation that only holds for a few. Those where George's concerns, but I was interested in knowing whether the planner transforms a query in any way to avoid, let's say, useless execution. George didn't provide the inside of his view, but it's possible that my earlier example could be rephrased as follows: create view v_foo as select * from tab where x < 5; select * from v_foo where x = 10; Presumably the planner has to transform the SELECT into select * from tab where x < 5 and x = 10; or something analogous. This is a simple example, but with complicated views or even joins and aggregates, the "useless execution" may not be that obvious to the "naked eye" but it would be to a boolean logic analyzer. As to whether these query instances represent few or are typical is arguable, and will depend on the type of application, level of knowledge among users, and what kind of interfaces are used to enter or generate the queries. Joe