[SERVER-77886] use SeekableRecordCursor::saveUnpositioned() when possible Created: 07/Jun/23 Updated: 06/Sep/23 Resolved: 30/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Colin Stolley | Assignee: | Colin Stolley |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
SeekableRecordCursor::saveUnpositioned() saves us an extra seek upon restoring from a yield. In classic engine, this was done for fetches as well as in index scans, but in SBE we never take advantage of this. This causes a loss in performance. For fetches, we never care about restoring the cursor location because we only return one result, so successive seeks never happen. For index scans, we can use saveUnpositioned when the scan is in the NeedSeek state. Porting these speed-ups to SBE will win back quite a bit of performance for snapshot_reads as well as mixed_workloads benchmarks. |
| Comments |
| Comment by Colin Stolley [ 06/Sep/23 ] |
|
ger.hartnett@mongodb.com yes, the applicable refactor would be https://jira.mongodb.org/browse/SERVER-77968 . The nub of the issue is ScanStage in SBE is used for both fetches and scans, so we can't infer at runtime whether saveUnpositioned() is pointless or not. In classic there are distinct stages for each, so the optimization was straightforward. |
| Comment by Ger Hartnett [ 06/Sep/23 ] |
|
Hi colin.stolley@mongodb.com as part of the perf-tiger-team I'm looking at ideas that were tried during 7.0-blockers that could be worth revisiting. You mentioned "broader refactor is the way to go" in the last comment. Is there a ticket for the broader refactor you're thinking of? Does it mention saveUnpositioned() specifically? |
| Comment by Colin Stolley [ 30/Jun/23 ] |
|
Broader refactor is the way to go, so not moving forward on this approach. |