Feedback-ID: id4a34324:Fastmail
Date: Tue, 3 Feb 2026 09:41:51 -0500
From: Andres Freund <andres@anarazel.de>
To: John Naylor <johncnaylorls@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, Chao Li <li.evan.chao@gmail.com>, 
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: More speedups for tuple deformation
Message-ID: <lzgoxzbh2gel5w362revuwaecrsbjr44kjdzrewuejugcodkeq@ixymojwnylsy>
References: <CAApHDvpDxDFatUskuOfuM7A3VESrx8U7MtYnU_HiB0QLAg94zg@mail.gmail.com>
 <pmik622adey6fnddivkt4uvkulvnc6rasmq3tcbrzeglx4hsn7@f3x6e2eph3w5>
 <rvlc7pb6zn4kydqovcqh72lf2qfcgs3qkj2seq7tcpvxyqwtqt@nrvv6lpehwwa>
 <CAApHDvo1i-ycAcWnK3L7ZASTuM8mW46kvRqMaUHD46HSuJmx7A@mail.gmail.com>
 <p2oo6g2fg5nxbsspbyeauxhbyyi3zsx3tt4prkgju3j5qjo7lf@rjlhxusxzam2>
 <CAApHDvpbntG7V3_EsZ+w-V=jU-y8rFmv9RB1EDJm4sxKno-4UA@mail.gmail.com>
 <e7sto7tk5dk5hfyvoocaddnxcngemcmfvbuh23l32w5cssaizy@znuphjqug7qe>
 <CAApHDvpuEbhvH1ViCZRz5vks+_bGbEnPoEdZYAZXK76_isb_+Q@mail.gmail.com>
 <v6z545yozjtywghn5glujemu72z4i4ynadsc2xks4ejotdg7yl@4rry7ixwr4us>
 <CANWCAZabO1oj+khF+YNVpmkTQwRRyNJesbsBhRFL5emZJh3tow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANWCAZabO1oj+khF+YNVpmkTQwRRyNJesbsBhRFL5emZJh3tow@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/lzgoxzbh2gel5w362revuwaecrsbjr44kjdzrewuejugcodkeq%40ixymojwnylsy>
Precedence: bulk

Hi,

On 2026-02-03 12:24:39 +0700, John Naylor wrote:
> On Tue, Feb 3, 2026 at 7:33 AM Andres Freund <andres@anarazel.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