On Wed, Jul 3, 2019 at 3:44 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote: > On Tue, Jul 2, 2019 at 1:47 PM amul sul <sulamul@gmail.com> wrote: > > Attached version is rebase atop of the latest master head(c74d49d41c), thanks. > > Thanks! Will review.
I started reviewing this. Here is my initial review comments:
First of all, I agree with your view on hash partitioning:
"3. For hash partitioned tables however, we support partition-wise join only when the bounds exactly match. For hash partitioning it's unusual to have missing partitions and hence generic partition matching is not required."
which is cited from the commit message for the main patch "0002-Partition-wise-join-for-1-1-1-0-0-1-partition-matchi-v22.patch". (I think it would be better if we can extend the partition matching to the hash-partitioning case where there are missing partitions in future, though.) However, I don't think it's a good idea to do this refactoring, because that would lead to duplicating the code to check whether two given hash bound collections are equal in partition_bounds_equal() and partition_hash_bounds_merge() that will be added by the main patch, after all. To avoid that, how about calling partition_bounds_equal() from partition_hash_bounds_merge() in the main patch, like the attached?
Agree, your changes look good to me, thanks for working on it.
