pgsql: Avoid combinatorial explosion in add_child_rel_equivalences().

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: Avoid combinatorial explosion in add_child_rel_equivalences().
Дата
Msg-id E1hbXvR-0003wQ-KD@gemulon.postgresql.org
обсуждение исходный текст
Список 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(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock