Here are some changes suggested on top of v34 as per my previous mail.
These are mostly comment changes.
On Mon, 6 Apr 2020 at 13:59, Etsuro Fujita <etsuro.fuj...@gmail.com> wrote:
> On Sat, Apr 4, 2020 at 12:15 AM Etsuro Fujita <etsuro.fuj...@gmail.com>
> wrote:
> > Attached is the original patch (0001) and one patch (0002) with
> > changes including those by Tomas and Ashutosh.
>
> I merged the patches into one and rebased it against HEAD. Attached
> is a new version, in which I added the commit message as well. Does
> that make sense? If there are no objections, I’ll commit the patch.
>
I have no objections.
--
Best Wishes,
Ashutosh
diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index 13633841f3..d285e63b6b 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -1106,32 +1106,33 @@ into joins between their partitions is called partitionwise join. We will use
term "partitioned relation" for either a partitioned table or a join between
compatibly partitioned tables.
-The technique is extended to some cases where the joining tables don't have
-exactly the same partition bounds, by an advanced partition-matching
-algorithm: it checks to see if there is a relationship where each partition of
-one joining table matches/overlaps at most one partition of the other, and
-vice versa; in which case the join between the joining tables can be broken
-down into joins between the matching partitions (ie, the join relation is
-considerd partitioned), so the algorithm produces the pairs of the matching
-partitions, plus the partition bounds for the join relation, to allow
-partitionwise join for the join. The algorithm is implemented in
-partition_bounds_merge(). For an N-way join relation considered partitioned
-by this extension, not every pair of joining relations can use partitionwise
+Even if the joining relations do not have exactly same partition bounds,
+partitionwise join can be still applied by by using an advanced
+partition-matching algorithm. For both the joining relations, the algorithm
+checks whether for every given partition of given joining relation there
+existsa matching/overlapping partition in the other joining relation. In such a
+case the join between the joining relations can be broken down into joins
+between their matching/overlapping partitions. The join relation can then be
+considered partitioned. The algorithm produces the pairs of the
+matching/overlapping partitions, plus the partition bounds for the join
+relation, to allow partitionwise join for computing join. The algorithm is
+implemented in partition_bounds_merge(). For an N-way join relation considered
+partitioned this way, not every pair of joining relations can use partitionwise
join. For example:
(A leftjoin B on (Pab)) innerjoin C on (Pac)
-where A, B, and C are partitioned tables, and A has an extra partition
-compared to B and C. When considering partitionwise join for the join {A B},
-the extra partition of A doesn't have a matching partition on the nullable
-side, which is the case that the current implementation of partitionwise join
-can't handle. So {A B} is not considered partitioned, and thus the pair of
-{A B} and C considered for the 3-way join can't use partitionwise join. On
-the other hand, the pair of {A C} and B can use partitionwise join, because
-{A C} is considered partitioned, eliminating the extra partition (see identity
-1 on outer join reordering). The partitionwise joinability of the N-way join
-relation is determined based on the first pair of joining relations that are
-both partitioned and can use partitionwise join.
+where A, B, and C are partitioned tables. A has an extra partition compared to
+B and C. When considering partitionwise join for the join {A B}, the extra
+partition of A doesn't have a matching partition on the nullable side, which is
+the case that the current implementation of partitionwise join can't handle.
+So {A B} is not considered partitioned and the pair of {A B} and C considered
+for the 3-way join can not use partitionwise join. On the other hand, the pair
+of {A C} and B can use partitionwise join, because {A C} is considered
+partitioned by eliminating the extra partition (see identity 1 on outer join
+reordering). Whether an N-way join can use partitionwise join is determined
+based on the first pair of joining relations that are both partitioned and can
+use partitionwise join.
The partitioning properties of a partitioned relation are stored in its
RelOptInfo. The information about data types of partition keys are stored in
diff --git a/src/backend/partitioning/partbounds.c b/src/backend/partitioning/partbounds.c
index e4c74d6c03..8ff798fd17 100644
--- a/src/backend/partitioning/partbounds.c
+++ b/src/backend/partitioning/partbounds.c
@@ -70,8 +70,8 @@ typedef struct PartitionRangeBound
} PartitionRangeBound;
/*
- * Mapping from partitions of a partitioned relation to partitions of a join
- * relation supposed to be partitioned (a.k.a merged partitions)
+ * Mapping from partitions of a partitioned joining relation to partitions of a
+ * join relation being computed (a.k.a merged partitions)
*/
typedef struct PartitionMap
{
