Details
-
Improvement
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
5.0.0, 6.0.0
-
None
-
Query Optimization
-
Fully Compatible
-
v6.3, v6.0, v5.0
-
QO 2023-03-20, QO 2023-04-03
-
(copied to CRM)
Description
A query that uses $in on _id does not plan against a clustered index if one exists. If no suitable secondary index exists, we fall back to a collection scan.
This affects queries directly on time-series buckets collections.
test> db.createCollection('clustered', {clusteredIndex: {key: {_id: 1}, unique: true}})
|
test> db.clustered.find({_id: {$in: [0,1,2,3]}}).explain()
|
{
|
explainVersion: '1',
|
queryPlanner: {
|
namespace: 'test.clustered',
|
indexFilterSet: false,
|
parsedQuery: { _id: { '$in': [ 0, 1, 2, 3 ] } },
|
queryHash: '0D7870DC',
|
planCacheKey: '0D7870DC',
|
maxIndexedOrSolutionsReached: false,
|
maxIndexedAndSolutionsReached: false,
|
maxScansToExplodeReached: false,
|
winningPlan: {
|
stage: 'COLLSCAN',
|
filter: { _id: { '$in': [ 0, 1, 2, 3 ] } },
|
direction: 'forward'
|
},
|
rejectedPlans: []
|
},
|
Attachments
Issue Links
- causes
-
SERVER-76102 handleRIDRangeScan() sets hasCompatibleCollation wrong in recursive cases
-
- Closed
-
- is related to
-
SERVER-75063 Support more complex scan bounds for clustered index
-
- Backlog
-