| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrey Stikheev <andrey(dot)stikheev(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Performance degradation in Index searches with special characters |
| Date: | 2024-10-07 16:48:02 |
| Message-ID: | 68004ea9-da02-4403-96a5-991fc5025d03@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Stikheev | 2024-10-07 17:16:24 | Re: Performance degradation in Index searches with special characters |
| Previous Message | Thomas Munro | 2024-10-06 20:24:15 | Re: Performance degradation in Index searches with special characters |