Subject: Re: ICU integration
To: Peter Geoghegan <pg@heroku.com>
References: <85364fde-091f-bbc0-fec2-e3ede39840a6@2ndquadrant.com>
 <3a88fa29-275b-f547-9957-86d4b2cd68db@2ndquadrant.com>
 <CAM3SWZR-ndDTEuU_p0meRARYZ0gMqmyG9gE9pR-M7qwSdTEGzA@mail.gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <6261dcf6-5bd1-a4ce-a800-54b34d696b3e@2ndquadrant.com>
Date: Mon, 9 Jan 2017 15:25:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAM3SWZR-ndDTEuU_p0meRARYZ0gMqmyG9gE9pR-M7qwSdTEGzA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 1/7/17 10:01 PM, Peter Geoghegan wrote:
> It occurs to me that the comparison caching stuff added by commit
> 0e57b4d8b needs to be considered here, too. When we had to copy the
> string to a temp buffer anyway, in order to add the terminating NUL
> byte expected by strcoll(), there was an opportunity to do caching of
> comparisons at little additional cost. However, since ICU offers an
> interface that you're using that doesn't require any NUL byte, there
> is a new trade-off to be considered -- swallow the cost of copying
> into our own temp buffer solely for the benefit of comparison caching,
> or don't do comparison caching. (Note that glibc had a similar
> comparison caching optimization itself at one point, built right into
> strcoll(), but it was subsequently disabled.)

That might be worth looking into, but it seems a bit daunting to
construct a benchmark specifically for this, unless we have the one that
was originally used lying around somewhere.

-- 
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