From: | Dennis Haney <davh(at)diku(dot)dk> |
---|---|
To: | simon(at)2ndquadrant(dot)com |
Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recursive optimization of IN subqueries |
Date: | 2004-01-27 14:32:54 |
Message-ID: | 40167696.8030208@diku.dk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-01-27 14:49:57 | Re: Recursive optimization of IN subqueries |
Previous Message | Simon Riggs | 2004-01-27 14:13:28 | Re: Recursive optimization of IN subqueries |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-01-27 14:49:57 | Re: Recursive optimization of IN subqueries |
Previous Message | Dave Cramer | 2004-01-27 14:26:50 | index scan with functional indexes |