Re: Performance degradation in Index searches with special characters

Hi Joe,

Yes, it seems that the issue is indeed related to that glibc commit. I also
found a bug report that highlights a similar problem:
https://sourceware.org/bugzilla/show_bug.cgi?id=18441 .

Unfortunately, the situation doesn't look promising. As Carlos O'Donell
mentioned in his last comment back in 2019:

Carlos O'Donell 2019-05-09 20:44:56 UTC

> Hello. Is there any chance that the issues will be fixed? Unfortunately
> PostgreSQL Is unable to use ICU for some basic features (e.g., in the
> analyze operation).

"We haven't had anyone working on strcoll_l performance improvements. So
it's unlikely that this will get merged or reviewed any time soon."

On Mon, 7 Oct 2024 at 19:48, Joe Conway <mail(at)joeconway(dot)com> wrote:

> On 10/6/24 14:13, Tom Lane wrote:
> > Joe Conway <mail(at)joeconway(dot)com> writes:
> >> This is not surprising. There is a performance regression that started
> >> in glibc 2.21 with regard to sorting unicode. Test with RHEL 7.x (glibc
> >> 2.17) and I bet you will see comparable results to ICU. The best answer
> >> in the long term, IMHO, is likely to use the new built-in collation
> just
> >> released in Postgres 17.
> >
> > It seems unrelated to unicode though --- I also reproduced the issue
> > in a database with LATIN1 encoding.
> >
> > Whatever, it is pretty awful, but the place to be complaining to
> > is the glibc maintainers. Not much we can do about it.
>
> Yeah, my reply was imprecise.
>
> The regression was to strcoll in general. Specifically this commit which
> purports to improve performance but demonstrably causes massive
> regressions:
>
> https://sourceware.org/git/?p=glibc.git;a=commit;h=0742aef6
>
> --
> Joe Conway
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
>

--
Best regards,
Andrey Stikheev