[SERVER-16891] Special handling of "idhack" queries should be moved to query planner Created: 16/Jan/15  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: J Rassi Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-13685 refactor fast-path for _id queries to... Closed
Related
is related to SERVER-16380 Index scans on unique indexes check t... Backlog
Assigned Teams:
Query Optimization
Participants:

 Description   

The query idhack path (a performance optimization to reduce planning/execution overhead for operations with query predicates of the form {_id: <value>}) is currently supported by a plethora of special cases in the query execution path:

  • The CanonicalQuery::isSimpleIdQuery() method.
  • Logic in ParsedUpdate and ParsedDelete to skip canonicalization for idhack queries (and a method for the caller to force re-canonicalization for the case in which the id index is not present).
  • Logic in prepareExecution(), getExecutor(), getExecutorUpdate(), getExecutorDelete() to skip query planning for idhack queries and force manual stage tree construction.
  • The IDHackStage query execution stage (which includes, among other things, duplicated logic to handle the case where the document to be fetched is not in resident memory), and explain functionality for this stage.
  • Logic in PlanExecutor and elsewhere to handle the special case where CanonicalQuery is NULL.

This can be vastly simplified without incurring a significant performance penalty to these operations.

Instead of custom execution machinery, idhack queries should have custom planning machinery. The query planner can fast-track a single query solution for idhack queries (FETCH <= IXSCAN, with an optional projection), and custom logic can be added to the index scan stage to avoid use of the "end checker" for point queries against unique indexes (which is a performance win for all queries including an equality expression against a unique-indexed field, not just idhack queries).


Generated at Thu Feb 08 03:42:37 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.