]> granicus.if.org Git - postgresql/commit
Fix thinko in previous patch for optimizing EXISTS-within-EXISTS.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Jun 2011 18:33:20 +0000 (14:33 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 20 Jun 2011 18:33:54 +0000 (14:33 -0400)
commit5f129cf942bb16d5e6d9db01db1789c98116baa1
treec4f8db785552e9e473a32ee38fa448909aef1b9c
parentb8e287711c2f0ce2aed0c1eeb50bc0154025c289
Fix thinko in previous patch for optimizing EXISTS-within-EXISTS.

When recursing after an optimization in pull_up_sublinks_qual_recurse, the
available_rels value passed down must include only the relations that are
in the righthand side of the new SEMI or ANTI join; it's incorrect to pull
up a sub-select that refers to other relations, as seen in the added test
case.  Per report from BangarRaju Vadapalli.

While at it, rethink the idea of recursing below a NOT EXISTS.  That is
essentially the same situation as pulling up ANY/EXISTS sub-selects that
are in the ON clause of an outer join, and it has the same disadvantage:
we'd force the two joins to be evaluated according to the syntactic nesting
order, because the lower join will most likely not be able to commute with
the ANTI join.  That could result in having to form a rather large join
product, whereas the handling of a correlated subselect is not quite that
dumb.  So until we can handle those cases better, #ifdef NOT_USED that
case.  (I think it's okay to pull up in the EXISTS/ANY cases, because SEMI
joins aren't so inflexible about ordering.)

Back-patch to 8.4, same as for previous patch in this area.  Fortunately
that patch hadn't made it into any shipped releases yet.
src/backend/optimizer/prep/prepjointree.c
src/test/regress/expected/subselect.out
src/test/regress/sql/subselect.sql