On Thu, Aug 7, 2014 at 2:23 PM, Rod Taylor <rod.tay...@gmail.com> wrote: > While I'm sure it's not common, I've seen a couple of ten-million tuple > tables having a URL column as primary key where 98% of the entries begin > with 'http://www.' > > So, that exact scenario is out there.
Sure, that scenario is relatively common. My point was that that scenario, alongside a perfect logical/physical heap correlation, and alongside a frequent need to sort is uncommon. If you're able to get away with a "bubble sort best case" there, then the sort is going to be extremely fast relative to any other database system anyway, and you don't have too much to complain about. It's exactly the same wasted cost as in the general case (where the tuples aren't in order), except that it looks more expensive next to your unrealistically fast sort that you were very lucky to be able to get away with. I think the special pre-check for already sorted tuples within qsort() is at best only justified by scenarios like where a serial primary key index is reindexed. That's about it. You can totally alter the outcome of this case by inserting a single tuple, so the top-level pre-check fails. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers