> Uh ... why? The pushed-down restrictions should result in pruning
> away any prunable partitions at the scan level, leaving nothing for > the partitionwise join code to do.
It seems reasonable to me that the join condition can no longer be verified, since 'sc.sl = sg.sl' is now replaced by 'sg.sl = 5' so the join condition can no longer be validated.
It's true that the pruning would prune everything but one partition, in case we'd just have a single column partition key. But we don't. I don't see how pruning partitions should help in this case, since we are left with multiple partitions for both relations.
Regards Arne
From: Tom Lane <tgl@sss.pgh.pa.us> Sent: Thursday, August 1, 2019 4:14:54 PM To: Richard Guo Cc: Arne Roland; pgsql-hackers@lists.postgresql.org Subject: Re: Partial join
Richard Guo <riguo@pivotal.io> writes: > For the third query, a rough investigation shows that, the qual 'sl = > 5' and 'sc.sl = sg.sl' will form an equivalence class and generate two > implied equalities: 'sc.sl = 5' and 'sg.sl = 5', which can be pushed > down to the base rels. One consequence of the deduction is when > constructing restrict lists for the joinrel, we lose the original > restrict 'sc.sl = sg.sl', and this would fail the check > have_partkey_equi_join(), which checks if there exists an equi-join > condition for each pair of partition keys. As a result, this joinrel > would not be considered as an input to further partitionwise joins.
> We need to fix this.
Uh ... why? The pushed-down restrictions should result in pruning away any prunable partitions at the scan level, leaving nothing for the partitionwise join code to do.