Comment 6 for bug 715749

Just for the record, this is the comment I added on Quentin's merge proposals against 5.0 and 6.0, where he added in-memory sorting of read's result:

~~~
Quentin, thank you for the merge proposal, however we cannot accept such a change in stable branches, like 5.0 or 6.0.
You may want to re-submit against the trunk version only.

But even for trunk, this in-memory sorting of the results of read() can be a performance problem, and this is the reason why read() does not re-sort the result when it returns them.
Read() is basically a "SELECT [fields] from table where id in [ids]" which postgres has no reason to sort in the order of [ids]. To be able to do that, read() should receive the sort order to use, and thus pass it in the SELECT query.

This requires an API change, and in order to avoid duplicating the features of search() there, it would probably make sense to implement this as part of a new combined search_read() method, that would do both things at the same time, using postgres to implement the ordering efficiently.

Hope this helps.