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
it can severely degrade performance due to
the extended processing time for string comparisons, especially in
high-traffic scenarios.
On Sun, 6 Oct 2024 at 19:39, Tom Lane wrote:
> Andrey Stikheev writes:
> >- Changing the collation to 'C' in the query significantly improv
Buffers: shared hit=1
Planning Time: 1.082 ms
Execution Time: 4425.602 ms
(9 rows)
Time: 4433.001 ms (00:04.433)
Observations*:*
- The performance degradation occurs with certain special characters
like < , !, >, @ , #, ... .
- Queries using alphabetic characters or appending/prepending characters
execute much faster.
- The execution time increases exponentially with the length of the
string composed of special characters.
- Changing the collation to 'C' in the query significantly improves
performance.
Questions*:*
- Is this performance degradation expected due to collation handling of
certain special characters in PostgreSQL?
- Are there any recommendations to improve performance without changing
the column or database collation?
--
Best regards,
Andrey Stikheev
