v1-0001-relax-bitmapand-restrictions.patch

application/x-patch

Filename: v1-0001-relax-bitmapand-restrictions.patch
Type: application/x-patch
Part: 0
Message: Re: Relaxing constraints on BitmapAnd eligibility?
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index a43ca16d68..f34d82f2e9 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -1767,16 +1767,16 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths)
 	 * because of the prefiltering step.  The cheapest of these is returned.
 	 *
 	 * We will only consider AND combinations in which no two indexes use the
-	 * same WHERE clause.  This is a bit of a kluge: it's needed because
-	 * costsize.c and clausesel.c aren't very smart about redundant clauses.
-	 * They will usually double-count the redundant clauses, producing a
-	 * too-small selectivity that makes a redundant AND step look like it
-	 * reduces the total cost.  Perhaps someday that code will be smarter and
-	 * we can remove this limitation.  (But note that this also defends
-	 * against flat-out duplicate input paths, which can happen because
-	 * match_join_clauses_to_index will find the same OR join clauses that
-	 * extract_restriction_or_clauses has pulled OR restriction clauses out
-	 * of.)
+	 * WHERE clauses that are subset of another. This is a bit of a kluge:
+	 * it's needed because costsize.c and clausesel.c aren't very smart about
+	 * redundant clauses. They will usually double-count the redundant
+	 * clauses, producing a too-small selectivity that makes a redundant AND
+	 * step look like it reduces the total cost. Perhaps someday that code
+	 * will be smarter and we can remove this limitation. (But note that this
+	 * also defends against flat-out duplicate input paths, which can happen
+	 * because match_join_clauses_to_index will find the same OR join clauses
+	 * that extract_restriction_or_clauses has pulled OR restriction clauses
+	 * out of.)
 	 *
 	 * For the same reason, we reject AND combinations in which an index
 	 * predicate clause duplicates another clause.  Here we find it necessary
@@ -1875,7 +1875,7 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths)
 
 			pathinfo = pathinfoarray[j];
 			/* Check for redundancy */
-			if (bms_overlap(pathinfo->clauseids, clauseidsofar))
+			if (bms_is_subset(pathinfo->clauseids, clauseidsofar))
 				continue;		/* consider it redundant */
 			if (pathinfo->preds)
 			{