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

Better replanning mechanism for SBE plans with blocking stages

    XMLWordPrintable

    Details

    • Type: Task
    • Status: In Progress
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
      None
    • Sprint:
      QE 2021-11-01

      Description

      Cached plans with blocking SORTS will completely stop (close()) and restart (open()) after the first 101 documents have been processed by the sort stage. These documents are discarded, and the work done by the plan up to this point is wasted.

       

      The strategy of aborting the plan mid-flight makes sense for multi-planning, when we want to run each plan for only a short duration to test its 'productivity'. However, for a plan already in the cache we should be "optimistic" about it remaining in the cache instead of paying the high cost of restarting the plan each time. Ideally, we'd have a solution which only aborts the query when it is clear that replanning is necessary.

       

      The way this is implemented is that a 'resultsBudget' is set in the SBE runtime planner when all of the plans are blocking. In the case of a cached solution, there is only one candidate, and if it is blocking, the resultsBudget is set, causing it to stop after a certain number of results have been fed into the sort stage.

        Attachments

          Activity

            People

            Assignee:
            justin.seyster Justin Seyster
            Reporter:
            ian.boros Ian Boros
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated: