-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Trivial - P5
-
None
-
Affects Version/s: None
-
Component/s: Aggregation Framework, Querying
-
Query Execution
Once the cluster cursor returns any result, RouterStageMerge doesn't issue any new getMore. However the batch may haven't been filled up. If the result set isn't empty, RouterStageMerge should wait for ARM to return an EOF when ARM gets an empty batch rather than checking _arm.ready().
The following patch fixes it. However, if the batch size is enforced for getMore's, getMore's will always wait for a full awaitDataTimeout (1 second by default) if there isn't enough data to fill a batch. The original implementation can return some results earlier without waiting. The difference is interesting when resuming change streams where returning full batches is more efficient.
Unable to find source-code formatter for language: diff. Available languages are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, yaml
diff --git a/src/mongo/s/query/router_stage_merge.cpp b/src/mongo/s/query/router_stage_merge.cpp
index e571ed4ed2..fcf6f560fa 100644
--- a/src/mongo/s/query/router_stage_merge.cpp
+++ b/src/mongo/s/query/router_stage_merge.cpp
@@ -70,7 +70,7 @@ StatusWith<ClusterQueryResult> RouterStageMerge::awaitNextWithTimeout(ExecContex
invariant(_params->tailableMode == TailableMode::kTailableAndAwaitData);
// If we are in kInitialFind or kGetMoreWithAtLeastOneResultInBatch context and the ARM is not
// ready, we don't block. Fall straight through to the return statement.
- while (!_arm.ready() && execCtx == ExecContext::kGetMoreNoResultsYet) {
+ while (!_arm.ready() && execCtx != ExecContext::kInitialFind) {
auto nextEventStatus = getNextEvent();
if (!nextEventStatus.isOK()) {
return nextEventStatus.getStatus();