[SERVER-53762] Report aggregate execution stats in explain for the inner side of $lookup Created: 13/Jan/21 Updated: 29/Oct/23 Resolved: 01/Apr/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Mohammad Dashti (Inactive) |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | Query Execution 2021-03-08, Query Execution 2021-03-22, Query Execution 2021-04-05 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
As part of Now that we are tracking these values, it would be valuable for debugging/diagnostics to expose them in "executionStats" or "allPlansExecution" level explain output. We will need to choose which metrics are exposed, but I think it would at the very least include docs examined and keys examined. This would be especially helpful in understanding the performance properties of the subpipeline, since explain currently does not display the execution plan used on the inner side (see SERVER-22622). Any information in explain as to whether the $lookup subpipeline is cheap or expensive and why would be immensely helpful for query performance debugging scenarios. |
| Comments |
| Comment by jing xu [ 03/Aug/23 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
hi: , } }, | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mohammad Dashti (Inactive) [ 01/Apr/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks to andrew.paroski and david.storch for their detailed comments and code reviews, this issue is fixed via this commit. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 01/Apr/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Mohammad Dashti', 'email': 'mdashti@gmail.com', 'username': 'mdashti'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mohammad Dashti (Inactive) [ 25/Mar/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Talked to david.storch earlier today. Thanks to david.storch we could clarify some points about this issue: Let's take a running example from this test:
we can enable explain on it via adding explain("executionStats") or explain("allPlansExecution"):
Then, it will produce this explain output:
In this issue, we want to extend the stages[1] path (where $lookup stats are located) and add the following statistics from PlanSummaryStats:
Then, the stages[1] path in the above example will look like this:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Bevilacqua [ 15/Jan/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.storch SERVER-22622 covers what I'm looking for pretty well so a new ticket shouldn't be necessary. For this ticket the aggregate docs/keys scanned would still be an improvement. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 15/Jan/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
alex.bevilacqua we could definitely implement something like you suggest, but I would recommend that be tracked under a separate ticket. The work proposed here would be a very simple and natural extension of work already done under | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Bevilacqua [ 15/Jan/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.storch this is a great idea. Since each execution of the subpipeline could potentially use a difference plan, and each plan can potentially scan more than one index, maybe the keys/docs examined could be per-index for the $lookup? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Storch [ 13/Jan/21 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
christopher.harris alex.bevilacqua I assume this is something that you would find quite useful, but let me know if you have any further thoughts on priority or regarding the behavior proposed here. |