[SERVER-43657] Investigate whether there are situations in which we don't need to set batchSize to 0 when opening a cursor for a pipeline Created: 26/Sep/19  Updated: 04/Oct/23

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

Type: Improvement Priority: Major - P3
Reporter: Ted Tuckman Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-38761 Explore options for batch size when g... Backlog
is related to SERVER-45738 Sharded find operations wait for an e... Backlog
Assigned Teams:
Query Optimization
Participants:

 Description   

It looks like we do know whether an aggregate needs to be merged on a shard (here) before we set the batchSize (in this function, here). If we pass that value through to the function, we may be able to eliminate the need for a request to be sent with batchSize: 0



 Comments   
Comment by Charlie Swanson [ 01/Oct/19 ]

One thing to consider here: If we use a non-zero batchSize for establishing the cursors on the shards, then there's a possibility it will interact poorly with the shard versioning protocol and end up wasting more work. There is a benefit to doing as little as possible before verifying that all shards are on the same page with respect to shard versioning.

For example, if you had 10 shards and some active migrations, 8 shards might complete and get the first batch but 2 shards may have recently completed a migration so respond with an error. This means the whole aggregation needs to be retried, throwing out any work that those other 8 shards have done. We also have no way of interrupting the work on those other shards right now that I know of. We don't have a cursor ID yet, and no op ID that we can guess. So in the worst case these 8 shards will compute an hours-long grouping query to return the first batch only to then realize no one is interested in that response anymore.

That all said, for simple streaming queries this is likely a pretty good idea, especially if there's a limit. My understanding is that this is something we do for normal queries (find commands), just not for aggregates.

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