Only pick indexes based on a superset of filters when it's a strict superset, and fall back on ordinary tiebreakers otherwise.

This likely doesn't affect results in a meaningful way, but it produces cleaner output. (Example, when filtering on x, choose index [x] over [x, y], even though they match on the same number of filters.)

But it could matter if the other tiebreaker rules pick an index that can provide additional information to other parts of the analysis (like picking a unique index)

Author: nicktobey

sql/analyzer/costed_index_scan.go

@@ -537,13 +537,14 @@ func (c *indexCoster) updateBest(s sql.Statistic, hist []sql.HistogramBucket, fd
 			return
 		}
 
-		// If one index uses a superset of the filters of the other, we should always pick the superset.
-		if c.bestFilters.SubsetOf(filters) {
+		// If one index uses a strict superset of the filters of the other, we should always pick the superset.
+		// This is true even if the index with more filters isn't unique.
+		if c.bestFilters.SubsetOf(filters) && !c.bestFilters.Equals(filters) {
 			update = true
 			return
 		}
 
-		if filters.SubsetOf(c.bestFilters) {
+		if filters.SubsetOf(c.bestFilters) && !filters.Equals(c.bestFilters) {
 			return
 		}