Some queries that used to run with "explode for sort" optimization are turned off, so there explain output will be changed. One example is:

coll.createIndex({a: 1, b: 1, c: 1});
coll.find({a: {$gte: 1, $lte: 1}, b: {$in: [1, 2]}}).sort({c: 1})

Description of Linked Ticket

In related ticket SERVER-66459 we plan to implement a quick fix of simply prohibiting query solutions generated by "explode for sort" from getting cached. The work for this ticket is to re-enable the SBE plan cache in combination with explode for sort.

Doing so could be a bit tricky. One reason is that the decision of whether to explode is done based on analyzing the index bounds. However, there could be various interval evaluation trees (IETs) that could lead to these explodable bounds. We need to make sure that no matter the value of the parameters, the SBE plan is still correct.

Another complication is that the number of index scans resulting from the explosion can depend on the number of unique values in a $in. But the current SBE plan cache encoding does not incorporate the length of the $in or the number of unique values. Doing so would make the plan cache less effective, since it would result in reduced plan reuse for applications that use $in.

One idea for how to implement this is to have some kind of runtime explosion. That is, the cached plan itself would not necessarily contain all of the necessary branches beneath the SortedMergeStage. When the plan is recovered from the cache and the input parameter values bound in, we can create the correct number of cloned ixscan branches beneath the sorted merge, each referring to the correct (lowKey, highKey) pair from the runtime environment.