[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: File s-85436-const-cache.v1.diff     File s-85436-ref-counted-val.v1.diff    
Issue Links:
Related
is related to SERVER-80576 Microbenchmarks - investigate regress... Backlog
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.

Generated at Thu Feb 08 06:57:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.