[DOCS-15972] [Server] Make parameterized explode for sort plans work with the SBE plan cache Created: 22/Mar/23  Updated: 13/Nov/23  Resolved: 01/Aug/23

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 7.0.0-rc0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Dave Cuthbert (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-67576 Make parameterized explode for sort p... Closed
Participants:
Days since reply: 46 weeks ago

 Description   
Original Downstream Change Summary

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.


Generated at Thu Feb 08 08:14:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.