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
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 |