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

Investigate potential performance benefit from consulting the plan cache earlier

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

      For a lot of the OLTP workloads which we are currently focused on optimizing, we expect that the queries are relatively simple and that they almost always use the plan cache rather than go through full query optimization. For such workloads, the queries are often short-running and therefore overhead on the hot path is significant relative to the time spent doing query execution.

      For such queries, we should investigate whether it is possible to consult the plan cache earlier in the code path. For instance, if we wanted to make this change for find commands only, we could measure whether there is an advantage to trying to recover a plan from the plan cache in find_cmd.cpp rather than going through several layers of function calls in get_executor.cpp. As soon as we have a CanonicalQuery we should be able to encode the plan cache key in order to look for a matching plan cache entry.

      One complication is that right now we support both the classic and SBE plan caches. As a starting point, perhaps we can only make this change for queries that are identified as sufficiently simple during parsing, and for which we can predict whether the query should use SBE or the Classic Engine. The performance benefits may be different between Classic and SBE, since the set up of steps needed to prepare the plan for execution are very different between the two engines.

            Assignee:
            william.qian@mongodb.com William Qian
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: