Re: Optimization for lower(), upper(), casefold() functions.
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Alexander Borisov <lex.borisov@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
Date: 2025-03-15T20:07:44Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix headerscheck warning.
- 549ea06e4217 18.0 landed
-
Optimization for lower(), upper(), casefold() functions.
- 27bdec06841d 18.0 landed
-
Refactor convert_case() to prepare for optimizations.
- d3b2e5e1ab5c 18.0 landed
-
Improve performance of Unicode {de,re}composition in the backend
- 783f0cc64dcc 14.0 cited
On Fri, 2025-03-14 at 15:00 +0300, Alexander Borisov wrote: > I tried adding a loop to create tables, and everything looks fine > (v7). > Also removed unnecessary (hanging) global variables. Changed. I used a loop more similar to your first one (hash of arrays), and I left case_map_special outside of the loop. It a different type of array: rather than mapping to a codepoint, it maps to another index, and I think it's a different case (and needs a different comment). > > It's all about not getting too carried away. In my vision these > subroutines (user-defined functions) will have to be moved to perl > module (.pm) in the future, after the patch is committed, so that the > code can be used for Normalization Forms. I prefer to generalize when we have the other code in place. As it was, it was a bit confusing why the extra arguments and subroutines were there. Also, make_ranges() doesn't seem to do what is described in the comment: it produces a single range. I changed "> $limit" to ">= $limit", but then it generates 3 ranges, not two. I rewrote it to be more clear what's going on: * I used new looping logic that, at least to me, seems a bit simpler. * I changed the ranges from an array of 4 elements to a hash with 3 keys, which is more descriptive when using it. * I changed the terminology of a range so that it's Start and End, because $from and $to are used by branches() to mean something else. In branch(): * I got rid of the third element "VALUE" from the range. It was used to be the start of the next range, but there was already code in the caller to look ahead to the next range, so it didn't serve any purpose. * If we rely on some compiler optimizations, it might be possible to simplify branch() a bit, but I'm fine with the way it's done. When looking around, I didn't find a lot of material discussing this generated-branches approach. While it's mentioned a few places, I couldn't even find a consistent name for it. If you know of something where I can read some more analysis, please send a link. Committed. Thank you! Regards, Jeff Davis