Re: A problem about partitionwise join - Mailing list pgsql-hackers

From Richard Guo
Subject Re: A problem about partitionwise join
Date
Msg-id CAMbWs49wRS5CkrjEOZxCVLO+Vm5YE_XHrYh8FCQbyvW-OUoMCg@mail.gmail.com
Whole thread Raw
In response to Re: A problem about partitionwise join  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Responses Re: A problem about partitionwise join  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers

On Fri, Nov 6, 2020 at 11:26 PM Anastasia Lubennikova <a.lubennikova@postgrespro.ru> wrote:
Status update for a commitfest entry.

According to CFbot this patch fails to apply. Richard, can you send an update, please?

Also, I see that the thread was inactive for a while.
Are you going to continue this work? I think it would be helpful, if you could write a short recap about current state of the patch and list open questions for reviewers.

The new status of this patch is: Waiting on Author

Thanks Anastasia. I've rebased the patch with latest master.

To recap, the problem we are fixing here is when generating join clauses
from equivalence classes, we only select the joinclause with the 'best
score', or the first joinclause with a score of 3. This may cause us to
miss some joinclause on partition keys and thus fail to generate
partitionwise join.

The initial idea for the fix is to create all the RestrictInfos from ECs
in order to check whether there exist equi-join conditions involving
pairs of matching partition keys of the relations being joined for all
partition keys. And then Tom proposed a much better idea which leverages
function exprs_known_equal() to tell whether the partkeys can be found
in the same eclass, which is the current implementation in the latest
patch.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Corner-case bug in pg_rewind
Next
From: Fujii Masao
Date:
Subject: Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module