[SERVER-35833] Make all query execution stages within a PlanExecutor share one RecordCursor Created: 26/Jun/18  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: query-offsite, storch
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Query Execution
Participants:

 Description   

Currently, each FETCH stage within a query plan opens its own storage-level cursor for accessing the collection:

https://github.com/mongodb/mongo/blob/bdf6af1e48db8cb4a21e821068af4cc2faac7415/src/mongo/db/exec/fetch.cpp#L105-L106

For plans with many FETCH stages (e.g. a large indexed $or), this means that a single query can open many storage-level cursors. Having many storage cursors open at one time can be expensive. This can be easily avoided in the query layer by making a PlanExecutor's execution stages share a single RecordCursor. (If the plan is covered, it never accesses the collection, so the PlanExecutor will open zero RecordCursors rather than exactly one.)

This optimization is only valid for PlanExecutor instances which operate over a single collection. PlanExecutors which may involve several collections, i.e. those for aggregates involving more than one collection, will not open a shared RecordCursor.



 Comments   
Comment by David Percy [ 05/Oct/22 ]

This optimization is only valid for PlanExecutor instances which operate over a single collection. PlanExecutors which may involve several collections, i.e. those for aggregates involving more than one collection, will not open a shared RecordCursor.

Would it make sense for the PlanExecutor to keep 1 open cursor per collection?

Comment by Ana Meza [ 04/Oct/22 ]

As per the Quick Wins Triage meeting, we are sending this back to the Triage queue for further discussions with the team

Generated at Thu Feb 08 04:41:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.