Re: A worst case for qsort - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: A worst case for qsort
Date
Msg-id CAM3SWZRY5EwLM8oGWhYJ8ypvM5DAz2aOSEquYn+YR6y_ZLsKAg@mail.gmail.com
Whole thread Raw
In response to Re: A worst case for qsort  (Peter Geoghegan <pg@heroku.com>)
List 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 by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Quick doc fix
Next
From: Rod Taylor
Date:
Subject: Re: A worst case for qsort