There are two kinds of query plans we may consider here other than a full blocking sort:

1. For each distinct value of a (in order ascending), scan the entire b sub-range in the reverse direction. This would be a streaming plan.
2. For each distinct value of a (in order ascending), scan the entire b sub-range in order but put them into a blocking sort for just that sub-range. This should reverse them all but keep the disk accesses sequential. This is semi-streaming in that it doesn't need to block for all results, but will stop and start blocking for each "a" value.

Either of these plans will involve a high number of seek calls if "a" is high cardinality, which could make them not worth it compared to a blocking sort plan. The first plan would be better for very low "a" cardinality, and the second would be better for when there are very few number of "b" values per value of "a". So such plans would need to be considered with the query planner, ideally in a cost-based manner since our current cost model doesn't seem like it would take into account that the non-linear data accesses would be more expensive.