should nsNavHistory::ConstructQueryString() be setting "ORDER BY", since we're going to sort the results? from nsNavHistory::ConstructQueryString() // Sort clause: we will sort later, but if it comes out of the DB sorted, // our later sort will be basically free. The DB can sort these for free // most of the time anyway, because it has indices over these items. // // FIXME: do some performance tests, I'm not sure that the indices are getting // used, in which case we should just remove this except when there are max // results. Note, even for max results, we might be doing the culling after we get our results anyways, see bug #394508 separate for the "not using the db indices" issue in the comment, we might be sorting twice (once in the db and again in our places code). note, our sort comparators frequently contain second or even third level sort orders. in some cases we could do that with several "order by" clauses.

actually we are adding order by most of the time, it is quite clear that ordering a somehow already ordered group should end up being faster. some particular case is just too hard to do in the backend, bug 499985 covers part of this requiring sorting in SQL. Solving WFM since partly fixed.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv