There is no such approach, and it is not feasible in any RDBMS. It's a first-principle problem. If I told you to go through a phone book and find all the names starting with "wagner" and then sort those by phone number. Finding the names would be easy, but what kind of an index would help you sort that extracted list then by phone number? A main index on phone number, or even on name+phone-number, or even covering index would all offer Zero help for an extracted data set. If however you have two single indexes on name and on phone number and you gather all names except the "wagner"s then scanning the table in row-order for phone number to produce a list ordered so would be helpful, but it's a sliding scale that is much more often than not heavily outweighed on the side of locating the requested rows by index rather than walking the index for sorting purposes. I know of no RDBMS that even bothers with an optimization that suggests walking the index in sort order rather than lookup. Perhaps if no lookup index exists but one exists for the ordering? But by then your DB design and speed problems are much worse than it should be.