Optimization issue of branching UNION ALL

Поиск
Список
Период
Сортировка
От Andrey Lepikhov
Тема Optimization issue of branching UNION ALL
Дата
Msg-id 703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru
обсуждение исходный текст
Ответы Re: Optimization issue of branching UNION ALL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

Client report on a corner case have shown up possible minor 
non-optimality in procedure of transformation of simple UNION ALL 
statement tree.
Complaint is about auto-generated query with 1E4 simple union all's (see 
t.sh to generate a demo script). The reason: in REL_11_STABLE it is 
planned and executed in a second, but REL_12_STABLE and beyond makes 
matters worse: planning of such a query needs tons of gigabytes of RAM.

Superficial study revealed possibly unnecessary operations that could be 
avoided:
1. Walking across a query by calling substitute_phv_relids() even if 
lastPHId shows that no one phv is presented.
2. Iterative passes along the append_rel_list for replacing vars in the 
translated_vars field. I can't grasp real necessity of passing all the 
append_rel_list during flattening of an union all leaf subquery. No one 
can reference this leaf, isn't it?

In attachment you can see some sketch that reduces a number of planner 
cycles/copyings.

-- 
Regards
Andrey Lepikhov
Postgres Professional
Вложения

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

Предыдущее
От: "Takamichi Osumi (Fujitsu)"
Дата:
Сообщение: assertion failures on BuildFarm that happened in slab.c
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Simplifications for error messages related to compression