-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Optimization
-
Fully Compatible
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In the MixedWorkloads genny workload (high-value workload), there are queries of the form
findOne({id: <int>})
Note that the field id is not _id, but does have a secondary index.
This leads to a plan like
slots: '$$RESULT=s11 env: { s5 = Nothing, s3 = 1706728396314 (NOW), s10 = {"id" : 1}, s1 = TimeZoneDatabase(Asia/Dhaka...Africa/Addis_Ababa) (timeZoneDB), s2 = Nothing (SEARCH_META), s6 = Nothing
[3] limit 1
[2] nlj inner [] [s4, s7, s8, s9, s10]
left
[1] cfilter {(exists(s5) && exists(s6))}
[1] ixseek s5 s6 s9 s4 s7 s8 [] @"f86e4a9b-d340-47b9-9936-c2c880428773" @"id_1" true
right
[2] limit 1
[2] seek s4 s11 s12 s7 s8 s9 s10 [] @"f86e4a9b-d340-47b9-9936-c2c880428773" true false
The constant filter stage above the ixseek does not appear to be necessary since we know that the bounds will be constants and parameterized in the query.
This be obsoleted by SERVER-86237, but it might help with queries not covered by that ticket.