On Tue, Feb 6, 2018 at 4:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Feb 5, 2018 at 4:46 AM, Ashutosh Bapat
> <ashutosh.bapat@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