Some query plans we can identify as never being optimal, no matter the scenario (indexes, documents, etc). One example is a full ixscan + fetch with no filter for a query with no sort. As long as the index is not sparse, a collection scan is always preferable. We saw this behavior in SERVER-102227.

We can write a property-based test to search for patterns in plans that are never optimal. Then if we make a change to the enumerator, the test will fail if we see these types of plans.

Some ideas from ben.shteinfeld@mongodb.com:

• An index scan should not be followed by a SORT stage if the index scan can satisfy that sort.
• Filters on projected out fields should be removed