From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | simon(at)2ndquadrant(dot)com |
Cc: | "'Dennis Haney'" <davh(at)diku(dot)dk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Recursive optimization of IN subqueries |
Date: | 2004-01-27 17:27:31 |
Message-ID: | 23950.1075224451@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> 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 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?
I mean that if the unique-ifying implementation were used, it'd deliver
the wrong answer (too many rows out). You could possibly carry through
a set of extensions to check which kind of sub-SELECT was in use and not
apply transformations that aren't correct, but it'd be a great deal more
complexity for something of marginal value. As far as I've seen, people
don't use inequalities in ANY/ALL subselects very much, and so I'm not
excited about complicating the planner to support them better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Siracusa | 2004-01-27 18:00:15 | Adding missing FROM clause - thanks or no thanks? |
Previous Message | Tom Lane | 2004-01-27 16:56:43 | Re: Increase stored proc. parameters max count |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-27 17:33:01 | Re: index scan with functional indexes |
Previous Message | Peter Eisentraut | 2004-01-27 17:16:47 | Incorrect START TRANSACTION implementation |