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!