[SERVER-57880] Implement $top, $topN, $bottom, and $bottomN accumulators Created: 21/Jun/21  Updated: 29/Oct/23  Resolved: 20/Oct/21

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

Type: Task Priority: Major - P3
Reporter: Mihai Andrei Assignee: Mickey Winters
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Sprint: QE 2021-08-09, QE 2021-08-23, QE 2021-09-06, QE 2021-09-20, QE 2021-10-04, QE 2021-10-18, QE 2021-11-01
Participants:

 Comments   
Comment by Githook User [ 20/Oct/21 ]

Author:

{'name': 'Mickey. J Winters', 'email': 'mickey.winters@mongodb.com', 'username': 'mjrb'}

Message: SERVER-57880 Implement $top, $topN, $bottom, and $bottomN accumulators
Branch: master
https://github.com/mongodb/mongo/commit/1c5b61079bf081df648f3ce91c42bd5d9fd9d8c9

Comment by Pawel Terlecki [ 02/Sep/21 ]

I think you are right. It may be a premature optimization. In this case I see how it does not make sense to split this ticket.

Comment by Kyle Suarez [ 02/Sep/21 ]

mickey.winters and I discussed this at top-n standup and sprint planning. With Mickey's current implementation, we are not sure if a more specialized version for top is going to be that much faster than the proposed plan for topN in the attached pull request. Our plan is to prioritize benchmarks for these accumulators in PERF-2486 and then use those perf numbers to see if we can gain a noticeable improvement.

Comment by Pawel Terlecki [ 02/Sep/21 ]

For perf reasons, I feel that top and topN should have different implementations. Analogously, bottom and bottomN.

Btw. after shipping time-series top and bottom turned out to be highly requested features as they are much faster than first and last if indexes are not available. Maybe it is worth splitting this ticket to two and shipping $top and $bottom first.

cc: kyle.suarez

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