[SERVER-81429] Address regressions due to PathCompare [Eq] lowering change Created: 25/Sep/23  Updated: 16/Nov/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Militsa Sotirova Assignee: Backlog - Query Optimization
Resolution: Unresolved Votes: 0
Labels: M9
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Problem/Incident
is caused by SERVER-80235 [CQF] Lower PathCompare [eq] using cmp3w Closed
Related
related to SERVER-80987 [CQF] Investigate Eq --> cmp3w regres... Closed
Assigned Teams:
Query Optimization
Participants:
Linked BF Score: 5

 Description   

SERVER-80235 caused some perf regressions and my comment on SERVER-80987 describes an investigation done as to why those regressions happened. There is far more detail on that ticket, but the regressions seem to be because now there are two operators instead of one (BinaryOp + cmp3w vs BinaryOp). An idea described in the comment to address this is to have specialized cmp3w functions, one for each comparison, which do the appropriate comparison to 0 with the output of cmp3w. This may be more performant given that we always know we will be comparing against a constant for comparisons.



 Comments   
Comment by Militsa Sotirova [ 16/Nov/23 ]

Yes, essentially. I filed this ticket before the discussion about the confusion around type-bracketing/non type-bracketing operators so I just didn't use that language.

Comment by Timour Katchaounov [ 16/Nov/23 ]

Isn't the idea to have specialized cmp3w functions equivalent to the idea of implementing non-type bracketing versions of the SBE comparison operations?

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