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 10/6/24 14:13, Tom Lane wrote:
> Joe Conway <mail@joeconway.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
