From: Julien Rouhaud <rjuju123@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Daniel Verite <daniel@manitou-mail.org>
Subject: Re: ICU for global collation
Date: Tue, 11 Jan 2022 19:08:52 +0800
Message-ID: <20220111110852.t5oxfga57llm5cy2@jrouhaud> (raw)
In-Reply-To: <c3093547-6ce2-66ca-71de-3a3c633cfb02@enterprisedb.com>
References: <374f8048-9d87-462c-a8aa-d02ffca6525f@manitou-mail.org>
<d7060bf1-177c-e0f2-f13f-b857cdd1182e@2ndquadrant.com>
<525ef44f-52bf-505f-a491-07835d039424@enterprisedb.com>
<YdOvEAFGbfGY/47A@jrouhaud>
<bba413de-5548-3480-e8f8-1ced562a866b@enterprisedb.com>
<ed3baa81-7fac-7788-cc12-41e3f7917e34@enterprisedb.com>
<20220110032508.4eyz6m6mpvt622la@jrouhaud>
<20220110060027.egvaly4lskylo22f@jrouhaud>
<c3093547-6ce2-66ca-71de-3a3c633cfb02@enterprisedb.com>
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!
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: rjuju123@gmail.com, peter.eisentraut@enterprisedb.com, daniel@manitou-mail.org
Subject: Re: ICU for global collation
In-Reply-To: <20220111110852.t5oxfga57llm5cy2@jrouhaud>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox