| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: More speedups for tuple deformation |
| Date: | 2026-02-03 14:41:51 |
| Message-ID: | lzgoxzbh2gel5w362revuwaecrsbjr44kjdzrewuejugcodkeq@ixymojwnylsy |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-02-03 12:24:39 +0700, John Naylor wrote:
> On Tue, Feb 3, 2026 at 7:33 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > It's somewhat scary to see this level of code size increase in a case where
> > the compiler really has no information to think vectorizing really is
> > beneficial...
>
> I tried building on gcc 15.2 with -fno-tree-loop-vectorize, and the
> server .text segment was only 5kB smaller, but that may understate the
> impact on the decisions that get made.
5kB of instructions isn't nothing. But I guess the fact that most of our loops
are too complicated might be protecting us :)
> Maybe it's better to opt in for unrolling and vectorization?
I think I'd go for opting out. There's too many cases where it's going to be
hard to see the optimization potential, e.g. due to inlining etc. I do think
we probably should add an evolved version of those pragma macros I showed
(including perhaps also ones hinting the other way), and use them in the
places we manually analyzed...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-02-03 14:41:54 | Re: Add LIMIT option to COPY FROM |
| Previous Message | David G. Johnston | 2026-02-03 14:12:23 | Re: Add LIMIT option to COPY FROM |