[SERVER-50597] Explain against a pipeline containing $unionWith does not accurately count executionStats from sub-pipeline Created: 27/Aug/20  Updated: 02/Aug/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Nicholas Zolnierz Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: qopt-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-58888 $unionWith explain with mode "executi... Closed
is related to SERVER-50246 $unionWith explain loses information ... Closed
is related to SERVER-75108 Revisit implementation of explain for... Backlog
Assigned Teams:
Query Optimization
Operating System: ALL
Participants:

 Description   

When explaining a pipeline containing a $unionWith stage, we first exhaust the pipeline to gather the execution stats. For union, this may or may not involve building and targetting its sub-pipeline depending on the subsequent stages (e.g. $limit may allow us to stream results directly from the base collection without using the pipeline). Next, we will serialize the $unionWith stage, at which point we "re-run" the pipeline and gather the explain output for it.

There are separate issues with this depending on whether we're running in a sharded cluster:

1. If not sharded: the executionStats reported for the inner pipeline will not take into account subsequent stages such as $limit which could affect the nReturned stat.
2. If sharded: The initial pass to exhaust the pipeline does not actually pull from the sub-pipeline since the helper we delegate to will see the explain bit and run a scatter-gather to get the results from each shard instead of establishing cursors to iterate. This means that the union stage essentially gets a no-op pipeline back, and the executionStats reported by the union stage itself will not include any potential documents from the sub-pipeline.


Generated at Thu Feb 08 05:23:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.