When using the classic multi-planner for SBE, we need to find a way to deal with the fact that classic uses a "works" metric whereas SBE uses "numReads" in the context of replanning. When we retrieve an SBE plan from the SBE plan cache, we need to run a trial period and have some maximum "numReads" budget which, when exceeded, will trigger replanning. But when the plan was first selected with the classic multi-planner, we didn't use SBE so we have to infer the "numReads" value based on the classic engine's execution stats.

Our current design says that we set the "numReads" value in the SBE plan cache as "totalKeysExamined + totalDocsExamined". In order for this to work, these two numbers must be roughly equivalent in all cases. We should write a test to show that these two metrics are approximately equal. The test will run various explains using both SBE and classic (perhaps switching which engine is used by leveraging the new Persistent Query Settings feature) and assert that "numReads" is approximately equal to "totalKeysExamined + totalDocsExamined".

One scenario to test is one that requires repeated index seeks. Imagine, for example, that you have a query like {a: {$gt: 0, $lt: 9}, b: {$gt: 0, $lt: 9}} and a query plan using index {a: 1, b: 1}. Now imagine the data has lots of documents where a is in bounds but b is out of bounds:

• {a: 1, b: 11}
• {a: 2, b: 11}
• {a: 3, b: 11}
• ...

In this case, we would expect a high number of seeks. We expect that both "numReads" and "keysExamined" will incorporate these seeks, but should test explicitly that this will work as expected.

ivan.fefer@mongodb.com has a table of example scenarios which we might want to also test to make sure that "numReads" ~= "totalKeysExamined + totalDocsExamined".