Re: Improve the performance of Unicode Normalization Forms.

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Alexander Borisov <lex(dot)borisov(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve the performance of Unicode Normalization Forms.
Date: 2025-06-12 07:58:31
Message-ID: CANWCAZYoo4pPjAyRQ8LeMgB+ZPzxufRjqs_xwykOGFv6BwTAMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 11, 2025 at 7:27 PM Alexander Borisov <lex(dot)borisov(at)gmail(dot)com> wrote:
>
> 11.06.2025 10:13, John Naylor wrote:
> > On Tue, Jun 3, 2025 at 1:51 PM Alexander Borisov <lex(dot)borisov(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Perumal Raj 2025-06-12 08:07:44 Logical Replication slot disappeared after promote Standby
Previous Message Mihail Nikalayeu 2025-06-12 07:58:01 Re: Proposal for Improving Concurrent Index Creation Performance