[SERVER-84858] POC for mixed trees of PlanStages and DocumentSources Created: 10/Oct/19 Updated: 12/Jan/24 Resolved: 22/Nov/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Query 2019-11-04, Query 2019-11-18, Query 2019-12-02 |
| Participants: |
| Description |
|
See if we can allow a DocumentSource to have a PlanStage child and a PlanStage to have a DocumentSource child. This would allow PlanStages to appear inside a Pipeline at runtime. |
| Comments |
| Comment by David Storch [ 22/Nov/19 ] |
|
I ran this POC through the microbenchmarks here: https://evergreen.mongodb.com/version/5dd716903e8e864e154e0347. Looking at the data with this performance discovery view it appears that the performance impact of this change for queries with $unwind is acceptable. This might help to build a case that this route to PlanStage/DocumentSource unification is an acceptable one. However, we are not pursuing PM-276 further right now so I am closing this ticket. |
| Comment by David Storch [ 08/Nov/19 ] |
|
I have a very rough POC of a possible approach here: https://mongodbcr.appspot.com/536240001/. Before I go any further with this, I hope to collect some feedback from the team about whether we think this is worth exploring further. |