[SERVER-50121] Add 'min' and 'max' parameters to aggregate command Created: 05/Aug/20  Updated: 06/Dec/22  Resolved: 25/Aug/20

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

Type: New Feature Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Do Votes: 0
Labels: PM-234-M3, PM-234-T-data-clone, query-work-resharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-49293 Test collection bulk loader for resha... Closed
Related
is related to SERVER-39943 Create match expressions for aggregat... Closed
Assigned Teams:
Query
Participants:

 Description   

{
    aggregate: "mycoll",
    pipeline: [],
    min: {a: 4},
    max: {a: 6},
    hint: {a: 1},
    cursor: {},
}

Analogous to SERVER-39567, the aggregate command must also specify a hint if either the 'min' or 'max' parameters are specified.



 Comments   
Comment by Max Hirschhorn [ 14/Aug/20 ]

david.storch, the proposal to add min/max to the aggregation subsystem came from a conversation with Charlie and Bernard on the resharding design document.

If I have understood query language semantics correctly, then I believe

{$match: {$expr: {$gte: ["$_id", <resume _id>]}}}

wouldn't be subjected to type bracketing. However, we currently don't generate index bounds for {$expr: {$gte}} queries. I think SERVER-39943 is for allowing {$expr: {$gte}} queries to use an index? I want the index bounds to be [<resume _id>, MaxKey].

There was also an exchange between Charlie, Bernard, and me that {$expr: {$gte}} queries may not sort the same way as $sort. I wasn't sure the reason - is it due to array values? We aren't able to specify the {$sort: {_id: 1}} in the collection cloning for resharding pipeline anyway; distributed aggregation planning is unable to push down both a {$sort: {_id: 1}} stage and a {$lookup: {from: {db: "config", coll: "cache.chunks.*"}}} stage to the donor shards as part of the split pipeline. To work around this limitation, the plan is for the merging pipeline to implicitly assume the hint implies a _id:1 sort order and merge the results across different donor shards in sorted order.

Comment by David Storch [ 14/Aug/20 ]

max.hirschhorn I think this change is best avoided. The min and max find command parameters are awkward, and I wouldn't want to extend their reach to the aggregation subsystem. Instead, we should consider adding match expressions or expressions that allow the equivalent of the min/max predicate to be expressed.

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