[SERVER-61859] Investigate performance penalty of change streams optimizations in "shard lite" configuration Created: 02/Dec/21 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Justin Seyster | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Execution
|
| Operating System: | ALL |
| Sprint: | QE 2022-02-07 |
| Participants: |
| Description |
|
The change_streams_listen_throughput benchmark shows a roughly 7% performance loss in 5.2 (compared to 5.0) in the case where there is no `$match` stage to optimize. This tradeoff is reasonable in exchange for the substantial performance improvement available when `$match` can be optimized (especially considering that other variants show much less of a performance penalty), but it would be worthwhile to investigate the specifics of the loss and see if there are potential mitigations. |
| Comments |
| Comment by Ethan Zhang (Inactive) [ 07/Feb/22 ] |
|
Hi steve.la, I need to deprioritize again, to make room for the columnar project. Taking this out of the sprint. |