[SERVER-29223] Inconsistencies with Top tracking for aggregate command Created: 15/May/17  Updated: 06/Dec/22

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

Type: Bug Priority: Major - P3
Reporter: Charlie Swanson Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: neweng, query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Operating System: ALL
Participants:

 Description   

The aggregate command creates an entry in Top by using the AutoGetCollectionOrViewForReadCommand RAII class, but the lifetime of this object is shorter than the time we spend processing the command. It's declared within an inner scope here so that we can release the locks before we start executing the Pipeline (which is self-locking). This will cause the Top entry to be generated too early: right after we construct the execution machinery, but before we actually execute the pipeline.

Further, we recursively call runAggregate() when we are running an aggregate command on a view. This creates two oddities/problems:

  1. We will create another AutoGetCollectionOrViewForReadCommand in the recursive call, which will generate another Top entry.
  2. During the recursive call call, the 'outer' AutoGetCollectionOrViewForReadCommand object from the calling frame is still in scope, so that Top entry will include the execution time of the entire 'runAggregate', including execution time.

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