Consider a point query on fields "a" and "b", and we have indices on both fields. The plan enumerator will generate IX_SCAN and AND_SORTED plans. If 1) each index scan range is large, 2) the intersection set is small, and 3) the document to fetch is large, then the AND_SORTED plan should be the winner. However, the current multiplanner algorithm makes it impossible to select the AND_SORTED plan. See this comment for an extreme case.

Given that the AND_SORTED plan needs to scan two indices and find an intersection, it inevitably requires more index lookups than the IX_SCAN plan to return any document. This means that the productivity score must be lower for the AND_SORTED plan. Scanning two indices instead of one also means more work() calls are needed to exhaust the plan faster than the IX_SCAN plan, so the AND_SORTED plan cannot benefit from the EOF bonus. On top of these, we also give a small penalty to AND_SORTED plans as a tiebreaker.

This is unfair because although AND_SORTED takes more work() calls, each work() call may perform less work than each work() call of an IX_SCAN plan. For an IX_SCAN plan, each work() call means an index lookup and a fetch. But for an AND_SORTED plan, each work() call may only be an index lookup and no fetch since no intersection is found. However, the multiplanner only counts the number of work() calls at the root of the plan stage tree disregarding this non-uniformity.

One potential way to fix this is by counting the actual work performed by all the stages in the stage tree, instead of just counting the number of function calls. For example, we can count an index lookup and a fetch both as one unit of work. This means each call to work() will be two units of work in the IX_SCAN case, but it maybe only one unit of work in the AND_SORTED case. We can even go further and take into account the size of the fetched document.