Re: Recursive optimization of IN subqueries

Simon Riggs wrote:

>>Tom Lane writes
>>
>>In the second place, what the code is doing is dependent on an
>>understanding
>>of the semantics of IN; I'm not sure it's applicable to, say,
>> WHERE outervar > ANY (SELECT innervar FROM ...)
>>and it's definitely not applicable to
>> WHERE outervar > ALL (SELECT innervar FROM ...)
>>In particular, the optimization paths that involve unique-ifying the
>>subselect output and then using it as the outer side of a join would
>>definitely not work for these sorts of things.
>>
>>
>
>I'm not sure if I've understood you correctly in the section above. Are
>you saying that these types of queries don't have a meaningful or
>defined response? Or just that they wouldn't be very well optimized as a
>result of the unique-ifying code changes? Or have I just mis-read the
>thread...
>
>
I think Tom is refering to the context of the specific optimization.
The optimization we are discussing does nothing to correlated
subqueries, and a uncorrolated subquery with > ALL/ANY is actually a
computed constant and not a join.

--
Dennis