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

MERGE_SORT_STAGE can be used more aggressively when OR_STAGE index sort orders match

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Querying
    • Labels:
    • Sprint:
      Query 2020-04-06, Query 2020-04-20, Query 2020-05-04, Query 2020-05-18

      Description

      Currently, we only replace an OR_STAGE with a MERGE_SORT_STAGE when the sort order of the underlying indexes are shared and match the desired sort order of the query.

      The OR_STAGE uses unbounded memory to de-duplicate records. The MERGE_SORT_STAGE currently seems to do the same, but could be optimized to use far less memory than the OR_STAGE since duplicate records are coming in from child stages in the same order.

      Given that MERGE_SORT_STAGE can be optimized to avoid unbounded memory, we should consider aggressively using it instead of OR_STAGEs, and re-SORTing afterwards (which happens in the OR_STAGE case as well).

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-query-optimization Backlog - Query Optimization
              Reporter:
              david.hatch David Hatch
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated: