Subject: Re: ICU integration
References: <85364fde-091f-bbc0-fec2-e3ede39840a6@2ndquadrant.com>
 <3a88fa29-275b-f547-9957-86d4b2cd68db@2ndquadrant.com>
 <CAM3SWZT6YFtkkjUOGgzBV9_tMijz+s68YgDZi7Qc2sPdFnQ9Bw@mail.gmail.com>
 <6ee64972-fc4d-b169-7f25-0940118f59ce@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
To: Peter Geoghegan <pg@bowt.ie>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <8149a3ad-c3bb-4e5e-db01-2cfe533144b2@2ndquadrant.com>
Date: Thu, 9 Feb 2017 10:58:21 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <6ee64972-fc4d-b169-7f25-0940118f59ce@2ndquadrant.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers