[SERVER-72894] Use traverseP expression to build the sort key for the common key prefix case Created: 17/Jan/23 Updated: 17/Jan/23 Resolved: 17/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Rui Liu | Assignee: | Rui Liu |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | QE 2023-01-23 |
| Participants: |
| Description |
|
Use traverseP expression to build the sort key for the common key prefix case. We should make sure the expression for the common prefix is only calculated once. We might need to add a workload for a longer key prefix to make sure it doesn't regress. Preliminary perf: https://performance-analyzer.server-tig.prod.corp.mongodb.com/perf-analyzer-viz/?evergreen_version=63c582a232f4171734d0e297&evergreen_base_version=performance_550e070c93e80bdb4f256dd634128ad919395eb0&metrics_selection=Latency99thPercentile||ops_per_sec||Latency50thPercentile||OperationThroughput||tpmC||NewOrders||Duration||average_read_latency_us||95th_read_latency_us||99th_read_latency_us&percent_filter=0||100&z_filter=0||10 |
| Comments |
| Comment by Rui Liu [ 17/Jan/23 ] |
|
There seems to be some further complication regarding MQL semantics. The following text is from here: Q: One question I have is, can you give some more context about why it's necessary to fall back to the old key generation logic in the case where two of the components share a prefix A: "What's so tricky about the 'paths with a common prefix' case?", you might ask. Normally, we can compute the sort key for each part of the sort pattern Let's consider an example. Suppose our sort pattern is {"a.b":1, "a.c":1} and {a: [ {b:11,c:29}, {b:11,c:28}, {b:12,c:27}]} If we computed the sort keys for "a.b" and "a.c" independently, then the sort The classic execution engine will traverse the array in field "a" and search for . So the classic execution will I could implement this natively in SBE using TraverseStage. However, because I |