Re: Improve the performance of Unicode Normalization Forms.
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: Alexander Borisov <lex.borisov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-06-11T07:13:32Z
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 →
-
Use C11 char16_t and char32_t for Unicode code points.
- 3853a6956c3e 19 (unreleased) cited
On Tue, Jun 3, 2025 at 1:51 PM Alexander Borisov <lex.borisov@gmail.com> wrote: > 5. The server part "lost weight" in the binary, but the frontend > "gained weight" a little. > > I read the old commits, which say that the size of the frontend is very > important and that speed is not important > (speed is important on the server). > I'm not quite sure what to do if this is really the case. Perhaps > we should leave the slow version for the frontend. In the "small" patch, the frontend files got a few kB bigger, but the backend got quite a bit smaller. If we decided to go with this patch, I'd say it's preferable to do it in a way that keeps both paths the same. > How was it tested? > Four files were created for each normalization form: NFC, NFD, NFKC, > and NFKD. > The files were sent via pgbench. The files contain all code points that > need to be normalized. > Unfortunately, the patches are already quite large, but if necessary, > I can send these files in a separate email or upload them somewhere. What kind of workload do they present? Did you consider running the same tests from the thread that lead to the current implementation? -- John Naylor Amazon Web Services