Re: Query with high planning time at version 11.1 compared versions 10.5 and 11.0

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