[SERVER-79862] Exponential batch size growth in DocumentSourceCursor Created: 08/Aug/23  Updated: 14/Nov/23  Resolved: 08/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Task Priority: Major - P3
Reporter: Zixuan Zhuang Assignee: Zixuan Zhuang
Resolution: Fixed Votes: 0
Labels: auto-reverted
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Assigned Teams:
Query Execution
Backwards Compatibility: Fully Compatible
Sprint: QE 2023-11-13
Participants:
Linked BF Score: 135

 Description   

as part of the migration of $search to SBE, we will be using DocumentSourceCursor together with PlanExecutorSBE. Due to how DocumentSourceCursor batching works, there is a potential risk that the performance of some queries will significantly degrade. Specifically queries like:
{{[$search, $stageNotSupportedBySBE, $unwind, $limit] }}  will result in DocumentSourceCursor attempting to unnecessarily populate potentially a large batch of documents (4MB), which could potentially take multiple roundtrips to mongot, and then $limit may discard majority of that.This issue will not appear for "nicer" queries like:
{{[$search, $stagesSupportedBySBE..., $limit] }}  -> here $limit will be pushed down below DocumentSourceCursor and the application of $limit will be done eficiently.
[$search, $stageNotSupportedBySBEButReorderableWithSkipLimit..., $limit]  -> here despite $limit being outside of supported prefix, the $search stages will infer the limit and apply it properly (at least after https://jira.mongodb.org/browse/SERVER-78351 is fixed).This problem should go away once SBE supports all stages, however until then there is a risk that some queries may become really really slow. Is this a blocker for shipping the search on SBE?

Use exponential batch size growth in DocumentSourceCursor to avoid performance issue for particular queries in SBE.



 Comments   
Comment by Githook User [ 08/Nov/23 ]

Author:

{'name': 'zixuan zhuang', 'email': 'zixuan.zhuang@mongodb.com', 'username': 'leozzx'}

Message: SERVER-79862 Exponential batch size growth in DocumentSourceCursor
Branch: master
https://github.com/mongodb/mongo/commit/fb3b3e9ee0dc349006199adf740a0da50e73f51c

Comment by Githook User [ 08/Nov/23 ]

Author:

{'name': 'auto-revert-processor', 'email': 'dev-prod-dag@mongodb.com', 'username': ''}

Message: Revert "SERVER-79862 Exponential batch size growth in DocumentSourceCursor"

This reverts commit 5514f70805b6ea272238d9391b1d2deaefb5fee3.
Branch: master
https://github.com/mongodb/mongo/commit/93a2ebef8f8bfd28b6fc41df71d4c6c4c530c19b

Comment by Githook User [ 07/Nov/23 ]

Author:

{'name': 'zixuan zhuang', 'email': 'zixuan.zhuang@mongodb.com', 'username': 'leozzx'}

Message: SERVER-79862 Exponential batch size growth in DocumentSourceCursor
Branch: master
https://github.com/mongodb/mongo/commit/5514f70805b6ea272238d9391b1d2deaefb5fee3

Comment by Zixuan Zhuang [ 08/Aug/23 ]

The change I'd suggest is to use exponential batch size growth in DocumentSourceCursor. Start with something very small (1? 2? 4?) and then keep doubling with each subsequent batch. That means that we will
never request most than 2x of documents then we actually needed. And we will never do more than log2 batches than we actually needed. Which seems like a good balance.This should also help other agg pipeline cases, including classic (and SBE until entire pipeline is supported by SBE), where we were unable to pushdown limit into classic plan stages and instead have limit outside of it.

Generated at Thu Feb 08 06:42:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.