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

Revisit implementation of explain for $unionWith

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

      Before $unionWith was implemented, all DocumentSource derived classes followed the same implementation pattern for "executionStats" or ""allPlansExecution" verbosity explain operations. Namely, the explain is done in two phases:

      • First, the pipeline is fully executed and the resulting data discarded. That happens here. During execution, runtime stats are captured and stored inside the stages of the pipeline.
      • Second, Pipeline::writeExplainOps() is called. This is intended to serialize the pipeline and its runtime stats without actually doing any further query execution.

      $unionWith, however, does not work as described above. Rather than serializing its original subpipeline during DocumentSourceUnionWith::serialize() it issues an entirely new explain operation related to the subpipeline which may do further query execution. This goes against the typical design for aggregation explain and requires some special infrastructure in the MongoProcessInterface. It may have some benefit in that we are able to provide more detailed explain output in the case that the collection on the inner side is sharded. However, it seems worth at least looking into whether we can reimplement explain for $unionWith to avoid this complexity.

            Assignee:
            backlog-query-optimization [DO NOT USE] Backlog - Query Optimization
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: