On Thu, Aug 7, 2014 at 12:06 PM, Peter Geoghegan <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
