Here I’m using “secondary” to mean any “from” collection in the original query.

When picking the best single table access plan, two structures store the collection’s total size, CardinalityEstimator and SamplingEstimatorImpl. When planning for secondary collections during join reordering, the latter has the correct base collection cardinality (it varies per collection), but the former always uses the main collection’s cardinality. This leads to tasserts/incorrect CE computation.

There may be a related problem with the indexes considered during single table planning.

The fix is to ensure that when we are picking a single table access plan (for a secondary collections), that collection is treated as the “main”/“primary” one and is therefore the source for the base collection cardinality and the indexes considered.