Undo 8.4-era lobotomization of subquery pullup rules.
After the planner was fixed to convert some IN/EXISTS subqueries into
semijoins or antijoins, we had to prevent it from doing that in some
cases where the plans risked getting much worse. The reason the plans
got worse was that in the unoptimized implementation, subqueries could
reference parameters from the outer query at any join level, and so
full table scans could be avoided even if they were one or more levels
of join below where the semi/anti join would be. Now that we have
sufficient mechanism in the planner to handle such cases properly,
it should no longer be necessary to play dumb here.
This reverts commits 07b9936a0f10d746e5076239813a5e938f2f16be and
cd1f0d04bf06938c0ee5728fc8424d62bcf2eef3. The latter was a stopgap
fix that wasn't really sufficiently analyzed at the time. Rather
than just restricting ourselves to cases where the new join can be
stacked on the right-hand input, we should also consider whether it
can be stacked on the left-hand input.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/0816fad6eebddb8f1f0e21635e46625815d690b9
Modified Files
--------------
src/backend/optimizer/prep/prepjointree.c | 218 ++++++++++++++++++++---------
1 files changed, 149 insertions(+), 69 deletions(-)