Re: A worst case for qsort

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: A worst case for qsort
Дата
Msg-id CAM3SWZRY5EwLM8oGWhYJ8ypvM5DAz2aOSEquYn+YR6y_ZLsKAg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A worst case for qsort  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Aug 7, 2014 at 12:06 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I think that pre-sorted, all-unique text datums, that have all
> differences beyond the first 8 bytes, that the user happens to
> actually want to sort are fairly rare.

Actually, you could use that case to justify not doing strxfrm()
transformation of very large lists in the more general case, where
strxfrm() blobs aren't truncated/abbreviated, but our qsort() is used,
which goes against the strong recommendation of, just to pick an
example at random, the glibc documentation. It states: "Here is an
example of how you can use strxfrm when you plan to do many
comparisons. It does the same thing as the previous example, but much
faster, because it has to transform each string only once, no matter
how many times it is compared with other strings. Even the time needed
to allocate and free storage is much less than the time we save, when
there are many strings." [1]

Sure, that would still be better than the equivalent abbreviated keys
case, since no strcoll() tie-breakers are required, but it would still
be bad, and all because of our pre-check for sorted input.

[1] https://www.gnu.org/software/libc/manual/html_node/Collation-Functions.html
-- 
Peter Geoghegan



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

Предыдущее
От: Guillaume Lelarge
Дата:
Сообщение: Quick doc fix
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: A worst case for qsort