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

Consider removing exact number of elements in $in from plan cache key

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

      In SBE plan cache key, we encode the number of elements in $in if there is no sort in the query and the length of $in is less than max scans to explode:

      https://github.com/mongodb/mongo/blob/66d182d1e50b7bfa8866ca2c44917638a3758d79/src/mongo/db/query/canonical_query_encoder.cpp#L744

      This is done because of explode for sort SBE plan will have the number of branches equal to the number of elements in $in.

      SERVER-83777 made it so that if $in length is greater than max scans to explode (we don't need explode for sort), then $in length is not cached.

      SERVER-83712  makes it so that if there is no sort in query (we don't need to explode for sort), then $in length is not cached.

      From Storch: One idea for how to implement this is to have some kind of runtime explosion. That is, the cached plan itself would not necessarily contain all of the necessary branches beneath the SortedMergeStage. When the plan is recovered from the cache and the input parameter values bound in, we can create the correct number of cloned ixscan branches beneath the sorted merge, each referring to the correct (lowKey, highKey) pair from the runtime environment.

            Assignee:
            Unassigned Unassigned
            Reporter:
            adi.agrawal@mongodb.com Adi Agrawal
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: