[SERVER-67065] Add build variant + testing for SBE hybrid matching Created: 07/Jun/22  Updated: 06/Dec/22  Resolved: 21/Sep/22

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

Type: Task Priority: Major - P3
Reporter: Ian Boros Assignee: Backlog - Query Execution
Resolution: Won't Do Votes: 0
Labels: pm2697-m4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

Today, the hybrid matching logic will only be exercised by queries with a $lookup or $group in the main build. In the all feature flags build, the hybrid matching logic will not be used at all, since it is disabled when the SBE plan cache is used.

After some discussion with others, we've agreed to add a new build variant that runs with SBE full enabled, and the plan cache disabled, so that the hybrid matching logic is exercised more thoroughly.

In addition, we should write a JS test which exercises interesting match expression behavior before an SBE-compatible $group or $lookup.



 Comments   
Comment by David Storch [ 21/Sep/22 ]

We spoke offline and agreed to close this as "Won't Do". We're hoping to get rid of the "frankenmatcher" as soon as we can so we do not plan to add more testing for it.

Comment by David Storch [ 20/Sep/22 ]

mihai.andrei@mongodb.com I'm not sure I understand what you mean. As I understand it, the original intent of this ticket was to add testing for the "frankenmatcher". But we are trying to get rid of the "frankenmatcher" as part of the SBE perf project, which would render this ticket unnecessary.

Comment by Mihai Andrei [ 20/Sep/22 ]

The only concern I have is that we do eventually want to reintroduce this; would we want to link this as depending onĀ  SERVER-69112 ?

Comment by David Storch [ 07/Sep/22 ]

kyle.suarez@mongodb.com mihai.andrei@mongodb.com at this point I'd probably advocate for closing this as "Won't Do". Do you agree?

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