Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
Дата
Msg-id CAExHW5uFwP_1N7RV6s8piQBvygGH+rppS60nFNHB9DKEM04ShA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-performance


On Fri, Dec 7, 2018 at 11:13 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:





Robert, Ashutosh, any comments on this?  I'm unfamiliar with the
partitionwise join code.

As the comment says it has to do with the equivalence classes being used during merge append. EC's are used to create pathkeys used for sorting. Creating a sort node which has column on the nullable side of an OUTER join will fail if it doesn't find corresponding equivalence class. You may not notice this if both the partitions being joined are pruned for some reason. Amit's idea to make partition-wise join code do this may work, but will add a similar overhead esp. in N-way partition-wise join once those equivalence classes are added.



I looked at the patch. The problem there is that for a given relation, we will add child ec member multiple times, as many times as the number of joins it participates in. We need to avoid that to keep ec_member list length in check.

--
Best Wishes,
Ashutosh Bapat

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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
Следующее
От: Square Bob
Дата:
Сообщение: Fwd: amazon aroura config - seriously overcommited defaults? (May beOff Topic)