From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Avoid combinatorial explosion in add_child_rel_equivalences(). |
Date: | 2019-06-13 22:10:29 |
Message-ID: | E1hbXvR-0003wQ-KD@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/d25ea0127598dd0ad27a029215172f396fbd1009
Modified Files
--------------
src/backend/optimizer/path/equivclass.c | 49 ++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 13 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2019-06-13 22:32:29 | Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock |
Previous Message | Alvaro Herrera | 2019-06-13 21:32:14 | pgsql: Avoid spurious deadlocks when upgrading a tuple lock |