To: Alvaro Herrera <alvherre@commandprompt.com>
cc: George Pavlov <gpavlov@mynewplace.com>, pgsql-sql@postgresql.org
Subject: Re: huge disparities in =/IN/BETWEEN performance 
In-reply-to: <20070209021414.GU24069@alvh.no-ip.org> 
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>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Thu, 08 Feb 2007 23:14:14 -0300"
Date: Thu, 08 Feb 2007 22:50:05 -0500
Message-ID: <14273.1170993005@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alvaro Herrera <alvherre@commandprompt.com> writes:
> I think the principle here is that the system is not gonna waste cycles
> on dumb queries.  Supposedly, morphing "foo BETWEEN 10 and 10" into
> "foo=10" is not a trivial transformation, and it'd impose a planning
> cost on all non-dumb BETWEEN queries.

There's a datatype abstraction issue involved: what does it take to
prove that "x >= 10 AND x <= 10" is equivalent to "x = 10"?  This
requires a nontrivial amount of knowledge about the operators involved.
We could probably do it for operators appearing in a btree operator
class, but as Alvaro says, it'd be cycles wasted for non-dumb queries.

As for the IN case, I think we do simplify "x IN (one-expression)" to
"x = one-expression", but "x IN (sub-select)" is a whole 'nother matter,
especially when you're comparing it to a case where one-expression is
a constant and so the planner can get good statistics about how many
rows are likely to match.

			regards, tom lane