On Mon, Jul 8, 2019 at 5:03 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote:
> On Wed, Jul 3, 2019 at 3:44 PM Etsuro Fujita <etsuro.fuj...@gmail.com> > wrote: > > On Tue, Jul 2, 2019 at 1:47 PM amul sul <sula...@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: > > * 0001-Hash-partition-bound-equality-refactoring-v22.patch > > 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. Regards, Amul
