-
Type:
Task
-
Resolution: Won't Do
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Query Integration
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
For recording updates by _id in querystats, we currently re-parse the query field which includes the overhead of both creating an expression context and parsing. This has affected some update workloads that query by _id. https://github.com/10gen/mongo/blob/648bdf3f8c67fb20f92053b7e3349f7836f7d99e/src/mongo/db/query/query_shape/update_cmd_shape.cpp#L58-L71
We could directly construct the shape to gain back perf.
Maybe something like this:
BSONObj shapifyQuery(const ParsedUpdate& parsedUpdate, const SerializationOptions& opts) { // Use the already-parsed query ('q' field) if we have it to avoid re-parsing. if (parsedUpdate.hasParsedFindCommand()) { auto matchExpr = parsedUpdate.parsedFind->filter.get(); return matchExpr ? matchExpr->serialize(opts) : BSONObj{}; } // Fast path for simple _id queries - construct shape directly without parsing. // We know the query is something like {_id: <value>} const auto& query = parsedUpdate.getRequest()->getQuery(); BSONElement idElem = query["_id"]; tassert(11193001, "Expected simple _id query", !idElem.eoo()); BSONObjBuilder result; BSONObjBuilder idObj(result.subobjStart("_id")); opts.appendLiteral(&idObj, "$eq", idElem); idObj.doneFast(); return result.obj(); }
This is just some pseudocode - we would have to investigate to see if we can really only expect q fields with {_id: <value>} in this branch (i.e. can we have _id: {expression} here too?)