Re: A worst case for qsort

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: A worst case for qsort
Дата
Msg-id CAM3SWZTTSUUa0SWhDPqi9QR5TUqF5mhBcDsLAUdrXR6_4k9vzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A worst case for qsort  (Rod Taylor <rod.taylor@gmail.com>)
Список pgsql-hackers
On Thu, Aug 7, 2014 at 2:23 PM, Rod Taylor <rod.taylor@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David G Johnston
Дата:
Сообщение: Re: Fixed redundant i18n strings in json
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: A worst case for qsort