My mistake then. Better to check than let a logical hole in. Thanks for
letting me know, Simon

-----Original Message-----
On Behalf Of Dennis Haney
Sent: Tuesday, January 27, 2004 14:33
Cc: 'Tom Lane';
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 an
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

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.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
postedJan 23, '04 at 6:37p
activeJan 27, '04 at 5:28p



site design / logo © 2021 Grokbase