The reason I was thinking IN would work better is that from a parser point of view confronted with a series of expressions chained via boolean operators such as
expr OR expr OR expr
The back end code generated has to be generic to combat with different type of _expression_ such as equality, greater than, less than, or any fancy expressions. For example:
a == b OR c != d AND e > f OR g == h
Where as in the case of
a IN (1, 2, 3, 4)
is actually a subset of the above composite _expression_ because
1- the expressions are always equality of operand a with a literal value which means the operand can be cached (register)
2- the composite _expression_ is always an OR chained _expression_ where the first TRUE-ness would return the composite as TRUE (aka short circuit behavior)
I could be wrong...I have been wrong before...
Medi
On Dec 12, 2007 5:03 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Richard Broersma Jr <rabroersma@xxxxxxxxx> writes:Note that depending on which PG version you are testing, x IN (a,b,c)
> --- On Wed, 12/12/07, Medi Montaseri <montaseri@xxxxxxxxx > wrote:
>> based on your report, run time of OR is 0.275 ms and IN is
>> 0.314
>>
> postgres=# explain analyze select * from tellers where
>> bid in ('1','2');
> Two other options are:
> SELECT *
> FROM Tellers
> WHERE bin = ANY( '1', '2' );
is exactly equivalent to x=a OR x=b OR x=c (older versions), or to
x = ANY(ARRAYa,b,c]) (newer versions).I seriously doubt that one's gonna win ...
> SELECT T.*
> FROM Tellers AS T
> INNER JOIN ( VALUES ( '1' ), ( '2' ) ) AS B( bin )
> ON T.bin = B.bin;
regards, tom lane
