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-02-18T22:02:25Z

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 Tue, 2025-02-11 at 23:08 +0300, Alexander Borisov wrote:
> I tried the approach via a range table. The result was worse than
> without the table. With branching in a function, the result is
> better.
> 
> Patch v3 — ranges binary search by branches.
> Patch v4 — ranges binary search by table.

Thoughts on v3:

It looks like the top 5 bits of the offset are unused. What if we used
those bits for flags to indicate:

   HAS_LOWER
   HAS_UPPER
   HAS_FOLD
   HAS_SPECIAL
   HAS_TITLE

That way, we only need to look in the corresponding table if it
actually has an entry other than the codepoint itself.

It doesn't leave a lot of room if the tables get larger, but if we are
worried about that, we could eliminate HAS_TITLE, because I don't think
the performance for INITCAP() is as important as LOWER/UPPER/CASEFOLD.

Regards,
	Jeff Davis