Skip opfamily check in eclass_matches_any_index() when the index isn't a

tglsfdc · tglsfdc · commit bf0b6ac43c5d · 2008-09-12T14:56:13.000Z
btree.  We can't easily tell whether clauses generated from the equivalence
class could be used with such an index, so just assume that they might be.
This bit of over-optimization prevented use of non-btree indexes for nestloop
inner indexscans, in any case where the join uses an equality operator that
is also a btree operator --- which in particular is typically true for hash
indexes.  Noted while trying to test the current hash index patch.
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
@@ -9,7 +9,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.232 2008/08/14 18:47:59 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.233 2008/09/12 14:56:13 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1584,7 +1584,18 @@ eclass_matches_any_index(EquivalenceClass *ec, EquivalenceMember *em,
 		{
 			Oid			curFamily = families[0];
 
-			if (list_member_oid(ec->ec_opfamilies, curFamily) &&
+			/*
+			 * If it's a btree index, we can reject it if its opfamily isn't
+			 * compatible with the EC, since no clause generated from the
+			 * EC could be used with the index.  For non-btree indexes,
+			 * we can't easily tell whether clauses generated from the EC
+			 * could be used with the index, so only check for expression
+			 * match.  This might mean we return "true" for a useless index,
+			 * but that will just cause some wasted planner cycles; it's
+			 * better than ignoring useful indexes.
+			 */
+			if ((index->relam != BTREE_AM_OID ||
+				 list_member_oid(ec->ec_opfamilies, curFamily)) &&
 				match_index_to_operand((Node *) em->em_expr, indexcol, index))
 				return true;
 
