On Tue, Feb 6, 2018 at 4:04 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Feb 5, 2018 at 4:46 AM, Ashutosh Bapat > <ashutosh.ba...@enterprisedb.com> wrote: >> Here's patch taking that approach. > > I rewrote the comment in relation.h like this, which I think is more clear: > > /* > * Is given relation partitioned? > * > - * A join between two partitioned relations with same partitioning scheme > - * without any matching partitions will not have any partition in it but will > - * have partition scheme set. So a relation is deemed to be partitioned if it > - * has a partitioning scheme, bounds and positive number of partitions. > + * It's not enough to test whether rel->part_scheme is set, because it might > + * be that the basic partitioning properties of the input relations matched > + * but the partition bounds did not. > + * > + * We treat dummy relations as unpartitioned. We could alternatively > + * treat them as partitioned, but it's not clear whether that's a useful > thing > + * to do. > */
The comment says why it checks both bounds and part_scheme, but it doesn't explain why we check nparts, part_rels etc. My patch had that explanation. Or may be with these changes those checks are not needed. Should we remove those? Thanks for the commit. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
