"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Tom Lane writes
>> 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 corre
7;;
[EMAIL PROTECTED]
Subject: Re: [HACKERS] Recursive
optimization of IN subqueries
Simon Riggs wrote:
Tom Lane writes In the second place, what the code is doing is dependent on anunderstandingof the semantics of IN; I'm not sure it's applicable to, say, WHERE outervar > ANY (SELEC
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 (SE
> 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
> 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
