This test in particular demonstrates the problem when we apply to change pending for SERVER-87277 (delete backing BSONObj for ComparisonMatchExpression).
{$or: [{a: 1}, {a: 1}]}
Will first optimize to
{a: {$in: [1, 1]}}
as part of the $or -> $in rewrite. This rewrite currently will construct new BSON for each element of the $in operand. Then we recursively invoke MatchExpression optimization, which ends up destroying the $in and the backing BSON for [1, 1].
The recursive invocation will end up in the $in -> $eq rewrite, which currently initializes the $eq with a BSONElement.
- is depended on by
-
SERVER-87277 Reduce CanonicalQuery creation overhead by avoiding BSONObj creation
- Closed