Re: ICU for global collation
От | Julien Rouhaud |
---|---|
Тема | Re: ICU for global collation |
Дата | |
Msg-id | 20220111110852.t5oxfga57llm5cy2@jrouhaud обсуждение исходный текст |
Ответ на | Re: ICU for global collation (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: ICU for global collation
|
Список | pgsql-hackers |
On Tue, Jan 11, 2022 at 10:10:25AM +0100, Peter Eisentraut wrote: > > On 10.01.22 07:00, Julien Rouhaud wrote: > > > > So I tried to run Noah's benchmark to see if I could reproduce the slowdown. > > Unfortunately the results I'm getting don't really make sense as removing the > > optimisation brings a 15% speedup, and with a few more runs I can see that I > > have about 25% noise, so there isn't much I can do to help. > > Heh, I had that same experience, it actually got faster without the > optimization, but then got lost in the noise on further testing. Ah, so it's not just my machine :) > Looking back at those discussions, I don't think those old test results are > relevant anymore. In the patch that was being tested there, > pg_newlocale_from_collation(), did not contain > > if (collid == DEFAULT_COLLATION_OID) > return (pg_locale_t) 0; > > so the default collation actually went through most or all of the function > and did a lot of work. That would understandably be quite slow. But just > calling a function and returning immediately should not be a problem. > Otherwise, the call to check_collation_set() in varstr_cmp() and elsewhere > would be just as bad. I didn't noticed that. That definitely explain why the performance concern isn't valid anymore. > So, unless there are concerns, I'm going to see about making a patch to call > pg_newlocale_from_collation() even with the default collation. That would > make the actual feature patch quite a bit smaller, since we won't have to > patch every call site of pg_newlocale_from_collation(). +1 for me!
В списке pgsql-hackers по дате отправления: