Currently the cost model assigns a higher cost to an index with more fields in the key pattern (e.g. if the estimated number of keys scanned is the same, an index scan on {a: 1} will have a lower cost than one on {a: 1, b: 1}). However, depending on the query (e.g. if the query is on both a and b), choosing the longer index may be the better choice. (One thing that might already mitigate this issue is that the index on {a: 1, b: 1} might have better bounds and result in fewer keys scanned, which would result in a lower cost. But we should investigate this and have a sense of where this works and where it doesn't.)

In this ticket we should see if we can do something smarter in this case. It may be complicated because we are introducing a dependency of the cost model on the predicates in the query.

This may not make sense modularity-wise, but we could implement a separate step after costing to see if two plans have index scans over the same number of keys where one is a prefix of the other. And then we could compare the key patterns to the predicate to see if the longer one makes more sense.