[SERVER-79383] Investigate view benchmarks to see if there's any route to improving the overhead of query stats Created: 26/Jul/23 Updated: 16/Aug/23 Resolved: 16/Aug/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Joshua Lapacik (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | QO 2023-08-07, QO 2023-08-21 | ||||||||
| Participants: | |||||||||
| Description |
|
We are seeing some regressions in "Queries.IdentityView.UnindexedLargeInMatching", which probably are caused by us adding an additional parse of an expensive $in query. We should run some benchmarking to confirm the waste and then look to see if there's any way to avoid a re-parse between the query stats store and when we hand it off to run the view as an aggregation. |
| Comments |
| Comment by Charlie Swanson [ 16/Aug/23 ] |
|
moving this out of M0 into M1 since we have at least concluded there's nothing concerning in the rate limited case. |
| Comment by Githook User [ 31/Jul/23 ] |
|
Author: {'name': 'joshua', 'email': '80741223+jlap199@users.noreply.github.com', 'username': 'jlap199'}Message: |