[SERVER-46270] Optimize postBatchResumeToken and latestOpLogTimestamp retrieval in PlanExecutor Created: 20/Feb/20 Updated: 29/Oct/23 Resolved: 26/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Anton Korshunov | Assignee: | Anton Korshunov |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Sprint: | Query 2020-02-24, Query 2020-03-09 | ||||
| Participants: | |||||
| Description |
|
Currently, the find or getMore commands tries to retrieve a postBatchResumeToken for each document in a batch, unconditionally calling PlanExecutor::getPostBatchResumeToken() even though the execution tree doesn't contain a stage which can produce the token. Moreover, the implementation of the PlanExecutor::getPostBatchResumeToken() method is sub-optimal, as we traverse the entire execution tree trying twice to find either ChangeStreamProxyStage or CollectionScan. Similarly is PlanExecutor::getLatestOplogTimestamp(). We can optimize these methods to avoid the need to traverse the execution tree over and over again, and only call these methods when we know upfront that the execution can produce a postBatchResumeToken or latestOpLogTimestamp. |
| Comments |
| Comment by Githook User [ 26/Feb/20 ] |
|
Author: {'name': 'Anton Korshunov', 'username': 'antkorsh', 'email': 'anton.korshunov@mongodb.com'}Message: |