-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework
-
None
-
Fully Compatible
-
Query 2018-01-29, Query 2018-02-12, Query 2018-02-26, Query 2018-03-12
-
(copied to CRM)
-
0
In the case of an aggregation framework query the first batch of results asked from the mergerPart to the shards are done asynchronously, however when it needs to get a second batch to fullfill the query it is virtually mono-threaded as the call to getNext is synchronous.
I think it would be good to be able to overcome this limitation and make all subsequent fetches to be done in the background.
You can see here (https://github.com/ahom/jupyter-notebooks/blob/master/mongo_cs32044/notebook.ipynb) a representation of this behavior.
On the Y axis are the shards, on the X axis is the time. Starting from second batch seems is completely synchronous.
Cheers,
Antoine
- depends on
-
SERVER-33660 Once getMores include lsid, sharded aggregations with $mergeCursors can hang
- Closed
-
SERVER-32307 Make AsyncResultsMerger kill sequence issue killCursors without waiting for outstanding batches
- Closed
- is depended on by
-
SERVER-33280 Add a test to ensure that an error on one shard will proactively clean up any cursors from other shards
- Closed
-
SERVER-33323 Refactor $mergeCursors stage to allow it to be used to merge cursors on mongos
- Closed
- is duplicated by
-
SERVER-32014 scanAndOrder serverStatus metric should not be incremented for $sort stages that are merging pre-sorted results
- Closed
- related to
-
SERVER-24981 $project-$limit optimization has bad repercussion on pipeline splitting
- Closed