Re: More speedups for tuple deformation

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tender Wang <tndrwang(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, John Naylor <johncnaylorls(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: More speedups for tuple deformation
Date: 2026-03-20 01:18:12
Message-ID: CAApHDvpdAXFdKeDaMDf1ssvSc-38-POg8QRBTKHEg7dhGRXP-g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 20 Mar 2026 at 01:56, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Fri, 20 Mar 2026, 01:39 Tender Wang, <tndrwang(at)gmail(dot)com> wrote:
>> 1197 pg_assume(attlen > 0 || attlen == -1);
>> (gdb) p attlen
>> $1 = -2
>
>
> Thanks for the report. I'll look in detail in the morning when I'm at my computer again. I guess i'll need to add an extra parameter (that will be constant folded away during the inlining) to the deformed function to specify if cstrings can exist in the tuple, which seemingly needs to be true when deforming minimal tuples. I'd rather not lose that optimisation with heap tuples.

I've pushed a fix for this. A more simple recreator was:

with cte as materialized (select relname::cstring as relname from
pg_class) select relname from cte;

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Makhmutov 2026-03-20 01:32:20 Two issues leading to discrepancies in FSM data on the standby server
Previous Message Mihail Nikalayeu 2026-03-20 01:15:00 Re: Resetting snapshots during the first phase of [CREATE |RE]INDEX CONCURRENTLY