Horton

Re: Improve the performance of Unicode Normalization Forms.

John Naylor <johncnaylorls@gmail.com>

View thread
From: John Naylor <johncnaylorls@gmail.com>
To: Alexander Borisov <lex.borisov@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-06-12T07:58:31Z
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 →

  1. Use C11 char16_t and char32_t for Unicode code points.

On Wed, Jun 11, 2025 at 7:27 PM Alexander Borisov <lex.borisov@gmail.com> wrote:
>
> 11.06.2025 10:13, John Naylor wrote:
> > 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.
>
> Okay, then I'll leave the frontend unchanged so that the size remains
> the same. The changes will only affect the backend.

Sorry, I by "both paths" I meant make the frontend and backend the
same, because it's good for testing. In the "small table" patch, libpq
etc increase by about 1%, which is negligible. unicode_norm.o is only
bigger by 7kB -- That seems okay to me, especially considering
unicode_norm_srv.o is smaller by 27kB.

>  From these tests, we see 2x in some tests.

Nice!

-- 
John Naylor
Amazon Web Services