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

Better replanning mechanism for SBE plans with blocking stages

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 5.2.0
    • None
    • None
    • None
    • Fully Compatible
    • QE 2021-11-01, QE 2021-11-15
    • 184

    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

            justin.seyster@mongodb.com Justin Seyster
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: