aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-01-27 19:46:41 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2012-01-27 19:46:41 -0500
commit0816fad6eebddb8f1f0e21635e46625815d690b9 (patch)
treef9031f95d8a790611faf4c198d4df0695ec30a32 /src/backend/executor/nodeModifyTable.c
parente2fa76d80ba571d4de8992de6386536867250474 (diff)
downloadpostgresql-0816fad6eebddb8f1f0e21635e46625815d690b9.tar.gz
postgresql-0816fad6eebddb8f1f0e21635e46625815d690b9.zip
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.
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions