[SERVER-72049] [CQF] Test all plans for a single MQL query Created: 12/Dec/22  Updated: 20/Apr/23

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

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

Issue Links:
Depends
depends on SERVER-73552 [CQF] Add ability to enumerate all plans Closed
Related
related to SERVER-68063 Ability to define a sub-set of unit t... Closed
is related to SERVER-74869 [CQF] Add ability to select an altern... Open
Assigned Teams:
Query Optimization
Participants:

 Description   

Let's try the following:

  • Create a new C++ unit test in a new file, with similar dependencies as sbe_abt_test.cpp.
  • Write a single example:
    • query in MQL
    • input documents
    • index specs
  • Translate the query to ABT
  • Get the query results as naively as possible. For example:
    • Disable constant folding
    • Disable exploration rewrites
    • Use a ScanDef with no indexes
  • Generate all query plans:
    • Leave constant folding, exploration, everything else enabled.
    • Disable branch and bound.
    • Keep rejected plans.
    • Run OptPhaseManager once.
    • Write a new function that extracts all plans from the final memo.
  • Lower to SBE, and run, each plan.
  • Compare each result to the naive result.
    • Use sorting to ignore both field order, and document order.

In other words, this is a property test that holds the query and input data fixed, and asserts: all plans for this query are correct. This means optimization bugs can't hide behind costing decisions. But we still have control over which examples we test.

 

This will also be a good opportunity to test cost predictions.



 Comments   
Comment by David Percy [ 19/Jan/23 ]

If this style of test is too slow we could move it to a task separate from run_unittests: SERVER-68063

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