> You can't. Nor should you want to. Everybody with even a vague
> recollection of a computer science course knows that the cost of
> a sort is nlog(n) while reading from an index is linear with the
> number of records to be read. However the cost of reading records
> from the disk in index order - random relative to disk placement -
> overwhelms the cost of the sort. If you're reading a whole table,
> its much faster to read it in disk order and sort the result rather
> that rattle the disk around finding a record here, a record there.
>
> The exception is a query with a limit/first clause - but even there
> an index on A and a sort on B shouldn't be horribly expensive. If
> it is, then store a pseudo field that's like B, but inverted.
> That's what our descending indexes are.

But even then a lot of other RDBMS use indices to apply the in-memory sort *after* reading the records (and sometimes even while reading). This has the advantage of reading the data unordered and then applying the sort order of the existing index.
And besides that: on large datasets where records are consumed one at a time at a relatively low pace, reading the data from disk in index order would be cheaper on resources like memory and CPU. I'd think in either case (read then sort using index or read using index order) that should have an advantage over just resorting the data yourself on every access.

Mark
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01