-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Fully Compatible
-
QO 2023-12-11, QE 2023-12-25, QE 2024-01-08, QE 2024-01-22, QE 2024-02-05
-
1
SERVER-83470 introduces internalQueryFrameworkControl="trySbeRestrict" in a way that is simple and amenable to backport, but justin.seyster@mongodb.com proposed an improvement that we should make to it in the master branch. Logically each DocumentSource should declare its level of compatibility with SBE. At the moment there are three compatibility levels:
enum struct SbeCompatibility { // Not implemented in SBE. notCompatible, // Implemented in SBE but behind the featureFlagSbeFull flag. flagGuarded, // Implemented in SBE and enabled by default. fullyCompatible, };
However, "trySbeRestrict" effectively introduces a fourth level. We should add a fourth enum value and rename them like so:
enum struct SbeCompatibility { // Not implemented in SBE. notCompatible, // Requires featureFlagSbeFull to be set. New SBE features which are under // development can live under this feature flag until they are ready to be shipped. requiresSbeFull, // Requires the framework control knob to be "trySbe". Fully tested, complete // SBE features belong here. default, // Used for the narrow feature set that we expose when "trySbeRestricted" is on. noRequirements, };
In the code which decides whether a DocumentSource should be pushed down, we imagine defining a lambda function like so:
auto meetsRequirements = [&minRequiredCompatibility](SbeCompatibility stageCompatibility) {
return stageCompatibility >= minRequiredCompatibility;
}
That way the callsites would be more readable. For instance, when asking whether a $unwind can be pushed down, you could do something like this:
meetsRequirements(SbeCompatibility::requiresSbeFull);
Unlike SERVER-83470, this ticket should not be backported.