[COMPASS-6639] Investigate changes in SERVER-67576: Make parameterized explode for sort plans work with the SBE plan cache Created: 22/Mar/23  Updated: 22/Mar/23  Resolved: 22/Mar/23

Status: Closed
Project: Compass
Component/s: None
Affects Version/s: None
Fix Version/s: No version

Type: Investigation Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-67576 Make parameterized explode for sort p... Closed
Documentation Changes: Not Needed

 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.



 Comments   
Comment by Jessica Sigafoos [ 22/Mar/23 ]

No changes needed on our end.

Generated at Wed Feb 07 22:43:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.