Re: Recursive optimization of IN subqueries - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Recursive optimization of IN subqueries
Date
Msg-id 23950.1075224451@sss.pgh.pa.us
Whole thread Raw
In response to Re: Recursive optimization of IN subqueries  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Incorrect START TRANSACTION implementation
Next
From: Tom Lane
Date:
Subject: Re: index scan with functional indexes