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.
src/backend/optimizer/prep/prepjointree.c | 218 ++++++++++++++++++++---------
1 files changed, 149 insertions(+), 69 deletions(-)
pgsql-committers by date
|Next:||From: Tom Lane||Date: 2012-01-28 04:10:28|
|Subject: pgsql: Fix error detection in contrib/pgcrypto's encrypt_iv() anddecry|
|Previous:||From: Peter Eisentraut||Date: 2012-01-27 20:02:45|
|Subject: pgsql: Show default privileges in information schema|