Versions 2.6.x and 3.0.x will not create a plan cache entry for a query shape if, during plan selection, either

1. the winning plan ties with the runner-up, or
2. the winning plan does not produce any results during the MultiPlanStage trial period.

The intention behind this behavior is that in these edge cases the system has low confidence that it has selected the best plan. In order to avoid re-using the wrong plan from the cache for a subsequent execution of the query shape, the system refrains from creating a potentially erroneous cache entry.

In version 3.1.2 under SERVER-15225, behavior was introduced to aggressively evict bad cache entries. This aggressive eviction obviated the need for not caching in case of ties or zero results, and therefore the system changed to always create a cache entry.

However, due to a detail in the implementation of the SubplanStage, $or queries which use the subplan path do not benefit from SERVER-15225's plan cache eviction logic. This means that subplanned queries can experience a performance regression in which they choose the wrong plan in 3.1.x unstable releases greater than or equal to 3.1.2.

We should correct this regression by re-introducing the "don't cache ties or zero result queries", just for queries that use the SubplanStage.