Simon Riggs wrote: <blockquote cite="mid002501c3e4df$be91c510$5e00030a@LaptopDellXP" type="cite"><blockquote
type="cite"><prewrap="">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 toWHERE 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. </pre></blockquote><pre wrap="">
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... </pre></blockquote> I think Tom is refering to the context of the specific optimization.<br /> The
optimizationwe are discussing does nothing to correlated subqueries, and a uncorrolated subquery with > ALL/ANY is
actuallya computed constant and not a join.<br /><br /><pre class="moz-signature" cols="72">--
Dennis
</pre>
