Avoid combinatorial explosion in add_child_rel_equivalences().
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Jun 2019 22:10:08 +0000 (18:10 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Jun 2019 22:10:20 +0000 (18:10 -0400)
commitd25ea0127598dd0ad27a029215172f396fbd1009
tree0e4734c2d5a996ede714b6e72f65c9b2d2936ac5
parentde87a084c0a5ac927017cd0834b33a932651cfc9
Avoid combinatorial explosion in add_child_rel_equivalences().

If an EquivalenceClass member expression includes variables from
multiple appendrels, then instead of producing one substituted
expression per child relation as intended, we'd create additional
child expressions for combinations of children of different appendrels.
This happened because the child expressions generated while considering
the first appendrel were taken as sources during substitution of the
second appendrel, and so on.  The extra expressions are useless, and are
harmless unless there are too many of them --- but if you have several
appendrels with a thousand or so members each, it gets bad fast.

To fix, consider only original (non-em_is_child) EC members as candidates
to be expanded.  This requires the ability to substitute directly from a
top parent relation's Vars to those of an indirect descendant relation,
but we already have that in adjust_appendrel_attrs_multilevel().

Per bug #15847 from Feike Steenbergen.  This is a longstanding misbehavior,
but it's only worth worrying about when there are more appendrel children
than we've historically considered wise to use.  So I'm not going to take
the risk of back-patching this.

Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org
src/backend/optimizer/path/equivclass.c