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

SBE Multiplanning can be slow when suboptimal plan runs first

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical - P2 Critical - P2
    • None
    • 5.1.1, 5.2.0-rc1, 6.0.12, 7.0.4
    • None
    • Query Execution
    • ALL
    • QE 2022-01-24, QO 2023-11-13, QO 2023-11-27

    Description

      Currently, the strategy used in SBE multiplanning is as follows:

      • We run non blocking plans before blocking ones.
      • We run each plan’s trial period to completion (i.e. until we return 101 documents or we use up the plans budget). We use the number of reads performed by said plan to bound the number of reads used by any remaining plans.

      The problem with this approach is that if the first plan we run is not the optimal one, we are stuck running it and we can potentially use all of the reads. As an example, consider two plans, A and B. Plan A needs to perform 10k storage engine reads to get 101 documents, while plan B needs to perform 101 reads to get 101 documents. If Plan B runs first, we have no problems: we will set the reads limit for plan A to 101, and it will stop running after 101 reads. If Plan A runs first however, we will be stuck running plan A for all 10k reads.  Though we’ll eventually run plan B and it will be chosen, this negatively impacts the performance of queries which need to use the multiplanner.

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            mihai.andrei@mongodb.com Mihai Andrei
            Votes:
            3 Vote for this issue
            Watchers:
            61 Start watching this issue

            Dates

              Created:
              Updated: