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.
Hmm..In the case of multiple partition keys, for range partitioning, if we have no clauses for a given key, any later keys would not be considered for partition pruning.
That is to day, for table 'p partition by range (k1, k2)', quals like 'k2 = Const' would not prune partitions.
For query:
select * from p as t1 join p as t2 on t1.k1 = t2.k1 and t1.k2 = t2.k2 and t1.k2 = 2;
Since we don't consider ECs containing consts when generating join clauses, we don't have restriction 't1.k2 = t2.k2' when building the joinrel. As a result, partitionwise join is not considered as it requires there existing an equi-join condition for each pair of partition keys.