Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-16891

Special handling of "idhack" queries should be moved to query planner

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: Querying
    • None
    • Query Optimization

      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).

            Assignee:
            backlog-query-optimization [DO NOT USE] Backlog - Query Optimization
            Reporter:
            rassi J Rassi
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: