[SERVER-60824] Support non-blocking sort() on cluster key Created: 19/Oct/21 Updated: 29/Oct/23 Resolved: 12/Apr/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Haley Connelly | Assignee: | Joel Redman (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-2311-M2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v5.0
|
||||||||||||||||||||||||||||||||||||||||
| Sprint: | QO 2022-03-07, QO 2022-03-21, Execution Team 2021-12-27, Execution Team 2022-01-10, Execution Team 2022-01-24, QO 2022-04-04, QO 2022-04-18 | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Description |
|
This should add support for reverse 'hint' as well. For time-series collections, this feature will support non-blocking sorts for queries directly against the buckets collection. Further work will be needed to support more efficient sorting by time against the time-series view. |
| Comments |
| Comment by Githook User [ 30/Jan/23 ] |
|
Author: {'name': 'James Wahlin', 'email': 'james@mongodb.com', 'username': 'jameswahlin'}Message: |
| Comment by Joel Redman (Inactive) [ 12/Apr/22 ] |
|
In the case that an index exists with a leading field matching the clustered key, that index will be chosen even if a fetch is required. This is due to a difference in how work occurs during a collection scan. For a standard index, the first work returns a value. For a collection scan (clustered or otherwise) the first return is always a WAIT. This appears to have something to do with support for tailable scans, but I wasn't able to determine the details. In any case, because of this WAIT, the collection scan always begins with a deficit for the multiplanner. |
| Comment by Githook User [ 12/Apr/22 ] |
|
Author: {'name': 'Joel Redman', 'email': 'joel.redman@mongodb.com', 'username': 'joredman'}Message: |
| Comment by Githook User [ 15/Feb/22 ] |
|
Author: {'name': 'Henrik Edin', 'email': 'henrik.edin@mongodb.com', 'username': 'henrikedin'}Message: reshard_collection_failover_shutdown_basic.js need to be disabled until |
| Comment by Louis Williams [ 02/Feb/22 ] |
|
The work in |
| Comment by Louis Williams [ 21/Jan/22 ] |
|
We want to avoid trying to special-case for time-series and make this apply to all clustered collections. However, if necessary, we may need to split this up into another ticket for time-series support for this feature. |
| Comment by Haley Connelly [ 26/Oct/21 ] |
|
Decided to send this over to QO and see if perhaps it belongs in PM-2556 if we don't find it urgent right now? |
| Comment by Haley Connelly [ 22/Oct/21 ] |
|
Assigning this to storage execution backlog until we determine if it is something worth borrowing someone from Query Optimization for |
| Comment by Haley Connelly [ 20/Oct/21 ] |
|
Originally, the idea was to mimic $natural sort/hint behavior similar to how $natural interprets a sort({$natural: +-1}) as a hint instead. However, the CanonicalQuery part of the code doesn't have access to the QueryPlannerParams which can be used to obtain the cluster key or the Collection() which also can be used to obtain the cluster key. When trying to introduce changes to the query planner / query analysis, we decided that someone with more expertise in this part of the codebase is more fit to make these changes. |