On Fri, Sep 23, 2016 at 7:27 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > A couple of thoughts about abbreviated keys: > > #ifndef TRUST_STRXFRM > if (!collate_c) > abbreviate = false; > #endif > > I think this macro should affect only strxfrm, and we should trust > ucol_getSortKey or disable it independently. ICU's manual says > reassuring things like "Sort keys are most useful in databases" and > "Sort keys are generally only useful in databases or other > circumstances where function calls are extremely expensive".
+1. Abbreviated keys are essential to get competitive performance while sorting text, and the fact that ICU makes them safe to reintroduce is a major advantage of adopting ICU. Perhaps we should consider wrapping strxfrm() instead, though, so that other existing callers of strxfrm() (I'm thinking of convert_string_datum()) almost automatically do the right thing. In other words, maybe there should be a pg_strxfrm() or something, with TRUST_STRXFRM changed to be something that can dynamically resolve whether or not it's a collation managed by a trusted collation provider (this could only be resolved at runtime, which I think is fine). > It looks like varstr_abbrev_convert calls strxfrm unconditionally > (assuming TRUST_STRXFRM is defined). <captain-obvious>This needs to > use ucol_getSortKey instead when appropriate.</> It looks like it's a > bit more helpful than strxfrm about telling you the output buffer size > it wants, and it doesn't need nul termination, which is nice. > Unfortunately it is like strxfrm in that the output buffer's contents > is unspecified if it ran out of space. One can use the ucol_nextSortKeyPart() interface to just get the first 4/8 bytes of an abbreviated key, reducing the overhead somewhat, so the output buffer size limitation is probably irrelevant. The ICU documentation says something about this being useful for Radix sort, but I suspect it's more often used to generate abbreviated keys. Abbreviated keys were not my original idea. They're really just a standard technique. -- 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
