Re: ICU for global collation - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: ICU for global collation
Date
Msg-id ed3baa81-7fac-7788-cc12-41e3f7917e34@enterprisedb.com
Whole thread Raw
In response to Re: ICU for global collation  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: ICU for global collation
List pgsql-hackers
On 04.01.22 17:03, Peter Eisentraut wrote:
>> There are really a lot of places with this new code.  Maybe it could 
>> be some
>> new function/macro to wrap that for the normal case (e.g. not 
>> formatting.c)?
> 
> Right, we could just put this into pg_newlocale_from_collation(), but 
> the comment there says
> 
>   * In fact, they shouldn't call this function at all when they are dealing
>   * with the default locale.  That can save quite a bit in hotspots.
> 
> I don't know how to assess that.

I tested this a bit.  I used the following setup:

create table t1 (a text);
insert into t1 select md5(generate_series(1, 10000000)::text);
select count(*) from t1 where a > '';

And then I changed in varstr_cmp():

         if (collid != DEFAULT_COLLATION_OID)
             mylocale = pg_newlocale_from_collation(collid);

to just

         mylocale = pg_newlocale_from_collation(collid);

I find that the \timing results are indistinguishable.  (I used locale 
"en_US.UTF-8" and made sure that that code path is actually hit.)

Does anyone have other insights?



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fix vcregress plpython3 warning
Next
From: Juan José Santamaría Flecha
Date:
Subject: Re: Fix vcregress plpython3 warning