| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | 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-01-31 06:01:44 |
| Message-ID: | CANWCAZYkQ+hYyr9L1rWJaKPKHZP__F1e1nCb6_d++ogB5bNEaw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 31, 2026 at 10:45 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Sat, 31 Jan 2026 at 15:48, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
> > pg_rightmost_one_pos32(~((uint32) bits[bytenum]))
>
> I'd rather handle that in a single byte as the fallback path in that
> function requires byte-at-a-time processing.
I spot checked some less common animals in the buildfarm and i686,
ppc64le, riscv64, loongarch64, and s390x all have the builtin. Of
these, only riscv64 seems to lack a single instruction implementation.
It's good to keep the old fallback path around just in case, but I
doubt a new fallback would get any coverage at all.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2026-01-31 06:52:10 | slow SELECT expr INTO var in plpgsql |
| Previous Message | Kirill Reshke | 2026-01-31 05:09:35 | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |