From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Alexander Borisov <lex(dot)borisov(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimization for lower(), upper(), casefold() functions. |
Date: | 2025-02-05 21:46:09 |
Message-ID: | 3ffb8b75b26e76624668c0883cac7886468c5d07.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2025-02-04 at 23:19 +0300, Alexander Borisov wrote:
> I've done many different experiments and everywhere the result is
> within
> the margin of the v2 patch result.
Great, thank you for working on this!
There doesn't appear to be a downside. Even though it's more complex,
we have exhaustive tests to compare with ICU, so that should catch any
correctness issues.
Heikki mentioned the radix tree, so I'd be interested to know what the
trade-offs there are. I don't have a strong opinion, but I'd like to be
able to explain why we use a radix tree for encoding conversions and
the generated branches approach in this patch for case mapping.
Also, I have a question: when there are deeply-nested "if" statements,
like in this patch, can that create a burden on the branch predictor
that affects code elsewhere?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2025-02-05 21:47:19 | Re: Update Unicode data to Unicode 16.0.0 |
Previous Message | Jelte Fennema-Nio | 2025-02-05 21:39:25 | Re: Windows CFBot is broken because ecpg dec_test.c error |