[SERVER-37140] Investigate what other StageConstraints are "inheritable" Created: 14/Sep/18  Updated: 06/Dec/22  Resolved: 05/Oct/18

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

Type: Improvement Priority: Major - P3
Reporter: Kyle Suarez Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-35419 Make diskRequirement in StageConstrai... Closed
Assigned Teams:
Query
Participants:

 Description   

In SERVER-35419, we're introducing a new helper that iterates over a pipeline of DocumentSources and "resolves" the strictest DiskUseRequirement and TransactionRequirement. This code is helpful for the $lookup and $facet stages, which have sub-pipelines of their own and "inherit" the strictest requirement of their children.

This ticket is to investigate what other StageConstraints should be inherited, if any. If there are more, we can genericize StageConstraints::resolveDiskUseAndTransactionRequirement()
to resolve all such constraints. charlie.swanson thinks that FacetRequirement might be eligible. ChangeStreamRequirement looks like it could be eligible, but the existence of kChangeStreamStage makes it seem difficult.



 Comments   
Comment by David Storch [ 05/Oct/18 ]

Closing per Charlie's comment above.

Comment by Charlie Swanson [ 24/Sep/18 ]

The code review for SERVER-35419 pointed out that it might make sense for stages with sub-pipelines to inherit their facet requirement from a sub-pipeline. This is actually an interesting question though. For example, if a facet allows a $lookup stage, should it only allow stages within the $lookup that might not otherwise be allowed within a facet? Some examples are $currentOp, $geoNear, $collStats. I actually can't recall whether these are allowed within a $lookup but I don't see any evidence that they are not. So I don't think we should make this change to 'inherit' the facet requirement through a $lookup or another $facet (though the nested $facet case doesn't really matter as much since clearly a stage which cannot be in a $facet would get caught either way).

The other constraints are: StreamType (streaming or blocking), Position Requirement (first, last, or none), HostTypeRequirement (5 choices), and ChangeStreamRequirement (whitelist, blacklist, or 'is a change stream stage'). None of those really make sense to 'roll up' to me either, so I'd recommend closing this.

david.storch agreed?

Comment by David Storch [ 21/Sep/18 ]

charlie.swanson to elaborate on the potential impact of the constraints implementation as it exists today.

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