Re: More speedups for tuple deformation

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

In response to

Browse pgsql-hackers by date

  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