[SERVER-85436] ABT Constant value pooling for efficient copying Created: 19/Jan/24 Updated: 31/Jan/24 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Timour Katchaounov | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Participants: | |||||||||
| Description |
|
As uncovered by SERVER-80576, nearly 40% of the optimization time of large $in queries is spent in copying the constant array argument of $in. This copying happens because of the ABT and Cascades designs that require ABT (sub)-trees to be copied when they are processed somehow. One way to speed up such copies when an ABT query representation references large Constant objects is to avoid copying the Value that is contained inside the Constant. The idea is that when a Constant is created to hold a new Value, the Value is stored in a constant pool, and then each subsequent invocation of Constant's copy constructor creates a new Constant that references the original Value. This approach will likely benefit only large enough values such as strings and arrays. |
| Comments |
| Comment by Timour Katchaounov [ 31/Jan/24 ] |
|
Given that work on Bonsai is paused, stopping progress on this ticket. Two alternative implementations are attached to the ticket. Both implementations result in nearly double performance improvement (based on Bonsai without SargableNode) - from 334 to 606 qps. With this improvement Bonsai is within 5% from Classic/SBE. |