"Simon Riggs" <simon@2ndquadrant.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

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 23, '04 at 6:37p
activeJan 27, '04 at 5:28p
posts7
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase