Re: More speedups for tuple deformation

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, 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-25 07:03:21
Message-ID: CANWCAZbpEb3LgBLoUU3kfKMvHRG=-ziLu1Z8VP76jry2Ky_VFg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 25, 2026 at 7:40 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Wed, 25 Feb 2026 at 07:33, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:

> > Won't this mix up column numbers on big-endian systems?
>
> Yes, I believe you're right. I've added the following before the memcpy().
>
> #ifdef WORDS_BIGENDIAN
>
> /*
> * Fix byte order on big-endian machines before copying to the array.
> */
> isnull_8 = pg_bswap64(isnull_8);
> #endif

I confirmed regression tests bail out early on a big-endian machine
with v9 and pass with v10.

--
John Naylor
Amazon Web Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-02-25 07:04:41 Re: Skipping schema changes in publication
Previous Message Chao Li 2026-02-25 06:59:05 Re: amcheck: fix bug of missing corruption in allequalimage validation