I don't believe this is a correctness or performance bug, currently. I think it will be a performance bug in the future if we enable SBE on time-series collections.
------
I noticed SBE implements the $_internalExpr operators differently than classic:
> db.c.find({x: {$_internalExprEq: 6}})
{ "_id" : ObjectId("61aa7b92b996804af1df48c9") }
{ "_id" : ObjectId("61aa8eb9c9ca709bfcca03e4"), "x" : null }
{ "_id" : ObjectId("61aa8ebbc9ca709bfcca03e5"), "x" : undefined }
{ "_id" : ObjectId("61aa8efcc9ca709bfcca03e6"), "x" : 6 }
{ "_id" : ObjectId("61aa910b6f5ffffd0b22b2a0"), "x" : 1 }
{ "_id" : ObjectId("61aa910d6f5ffffd0b22b2a1"), "x" : 100 }
> db.c.find({x: {$_internalExprEq: 6}}).explain().queryPlanner.winningPlan.slotBasedPlan.stages
[1] filter {true}
[1] scan s4 s5 none none none none [] @"25bb7ad1-c1c1-42fa-82cc-80e871af7bcb" true false
In the classic engine only {x: 6} would match.
I noticed because in time-series rewrites, we use these operators to filter down the set of buckets before unpacking. We're relying on the specific behaviors documented here: https://github.com/mongodb/mongo/blob/93e01aad220ee1ab5ae809acd09426da46e028d0/src/mongo/db/matcher/expression_internal_expr_comparison.h#L36-L53
I don't think it's a problem yet, because it also looks like we don't generate SBE plans for time-series collections. But if we do plan to enable SBE+timeseries I think we'll need to change this.
- is depended on by
-
SERVER-79699 Support wholeBucketFilter in the UnpackBucketNode stage
-
- Closed
-
- is duplicated by
-
SERVER-52745 Implement any MatchExpressions produced in SERVER-39943 in SBE
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Backlog
-
-
-
- Closed
-