Since our indexes are logically sorted sets of (key1, key2, ..., rowid) tuples that support seeking to any position, there is room for significant speedup by having AND_SORTED IX_SCAN plans seek in each index based on the lowest possible record id that could match given what other indexes have said. For example if the A index says that the next record id is 1000, we should seek the B index to skip to the next entry with a matching value that is >= 1000, since anything lower is guaranteed not to match. If B then says that 2000 is next, we should go back to A (or on to C if there are more indexes) and ask for >=2000, and keep going on like that until all indexes say the same rowid. This has the advantage of both significantly reducing the number of index entries we need to look at, as well as automatically taking advantage of the more selective index without needing to keep stats or use a fancy plan ranker.

Once we do this, it will be unconditionally better than the single IX_SCAN + fetch plans, so we should stop generating those plans and just always use AND_SORTED. At least for multi-field point queries. If any fields are range queries, it may be more nuanced.