From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ICU integration |
Date: | 2017-02-09 15:58:21 |
Message-ID: | 8149a3ad-c3bb-4e5e-db01-2cfe533144b2@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/24/17 12:45 PM, Peter Eisentraut wrote:
> On 1/9/17 3:45 PM, Peter Geoghegan wrote:
>> * I think it's worth looking into ucol_nextSortKeyPart(), and using
>> that as an alternative to ucol_getSortKey(). It doesn't seem any
>> harder, and when I tested it it was clearly faster. (I think that
>> ucol_nextSortKeyPart() is more or less intended to be used for
>> abbreviated keys.)
> I will try to look into that.
I think I have this sorted out. What I don't understand, however, is
why varstr_abbrev_convert() makes a point of looping until the result of
strxfrm() fits into the output buffer (buf2), when we only need 8 bytes,
and we throw away the rest later. Wouldn't it work to just request 8 bytes?
If there is a problem with just requesting 8 bytes, then I'm wondering
how this would affect the ICU code branch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-09 16:18:40 | Re: pageinspect: Hash index support |
Previous Message | Erik Nordström | 2017-02-09 15:30:57 | Re: Patch: Avoid precision error in to_timestamp(). |