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 CAExHW5umxU5FOoT8FBcqp-GWKMtZhnuEy7U6bNH8QfzvYwUgEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0  (Ashutosh Bapat <ashutosh.bapat.oss@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 Thu, Dec 6, 2018 at 1:27 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2018-Dec-06, Amit Langote wrote:

> The partitionwise join related
> changes in PG 11 moved the add_child_rel_equivalences call in
> set_append_rel_size such that child EC members would be added even before
> checking if the child rel is dummy, but for a reason named in the comment
> above the call:
>
>    ... Even if this child is
>  * deemed dummy, it may fall on nullable side in a child-join, which
>  * in turn may participate in a MergeAppend, where we will need the
>  * EquivalenceClass data structures.
>
> However, I think we can skip adding the dummy child EC members here  and
> instead make it a responsibility of partitionwise join code in joinrels.c
> to add the needed EC members.  Attached a patch to show what I mean, which
> passes the tests and gives this planning time:

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.

--
Best Wishes,
Ashutosh Bapat

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: 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