| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pgsql: Optimize tuple deformation |
| Date: | 2026-10-08 15:44:12 |
| Message-ID: | ddfdcaaf-3fe6-4a25-bf3f-1af56e2429aa@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
On 07.10.26 10:54, David Rowley wrote:
> On Wed, 7 Oct 2026 at 19:31, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> On 15.03.26 23:50, David Rowley wrote:
>>> Optimize tuple deformation
>>
>> This commit c456e391138 changed in slot_deform_heap_tuple() the type of
>> attnum from int to size_t, which seems unusual and doesn't fit with the
>> surrounding code. Could you check whether that was intentional?
>
> It was done to work around a problem with gcc where it was refusing to
> index the CompactAttribute array by adding 8 to the previous address
> to get the address of the next element. Instead, it was doing LEA on
> each loop, which was slower due to shift and add rather than just add.
> The best I could figure out is that gcc didn't want to optimise to use
> LEA due to concerns about the integer wrapping around, which, if it
> did, would be a different address than doing 2^31 adds on a 64-bit
> pointer.
Oh! :-/
How about a really big comment about that, and maybe change the type
from size_t to uint64 (or maybe uintptr_t, if it's supposed to vary on
32-bit platforms), so it looks more intentional and not like a mistake?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-10-08 16:24:49 | pgsql: Fix failure of setrefs.c to process child_append_relid_sets |
| Previous Message | Noah Misch | 2026-10-08 14:10:07 | pgsql: Update the branch retirement timeline to fit recent practice. |