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