"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 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
