pgsql: Refactor att_align_nominal() to improve performance.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Refactor att_align_nominal() to improve performance.
Date: 2026-02-02 19:40:01
Message-ID: E1vmzmC-000mMJ-2J@gemulon.postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Refactor att_align_nominal() to improve performance.

Separate att_align_nominal() into two macros, similarly to what
was already done with att_align_datum() and att_align_pointer().
The inner macro att_nominal_alignby() is really just TYPEALIGN(),
while att_align_nominal() retains its previous API by mapping
TYPALIGN_xxx values to numbers of bytes to align to and then
calling att_nominal_alignby(). In support of this, split out
tupdesc.c's logic to do that mapping into a publicly visible
function typalign_to_alignby().

Having done that, we can replace performance-critical uses of
att_align_nominal() with att_nominal_alignby(), where the
typalign_to_alignby() mapping is done just once outside the loop.

In most places I settled for doing typalign_to_alignby() once
per function. We could in many places pass the alignby value
in from the caller if we wanted to change function APIs for this
purpose; but I'm a bit loath to do that, especially for exported
APIs that extensions might call. Replacing a char typalign
argument by a uint8 typalignby argument would be an API change
that compilers would fail to warn about, thus silently breaking
code in hard-to-debug ways. I did revise the APIs of array_iter_setup
and array_iter_next, moving the element type attribute arguments to
the former; if any external code uses those, the argument-count
change will cause visible compile failures.

Performance testing shows that ExecEvalScalarArrayOp is sped up by
about 10% by this change, when using a simple per-element function
such as int8eq. I did not check any of the other loops optimized
here, but it's reasonable to expect similar gains.

Although the motivation for creating this patch was to avoid a
performance loss if we add some more typalign values, it evidently
is worth doing whether that patch lands or not.

Discussion: https://postgr.es/m/1127261.1769649624@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/da7a1dc0d62ac3141328f4e6ad51d70e918167aa

Modified Files
--------------
contrib/dblink/dblink.c | 4 +-
src/backend/access/common/tupdesc.c | 21 +----
src/backend/executor/execExprInterp.c | 8 +-
src/backend/utils/adt/array_expanded.c | 4 +-
src/backend/utils/adt/arrayfuncs.c | 149 +++++++++++++++++---------------
src/backend/utils/adt/multirangetypes.c | 16 ++--
src/backend/utils/adt/varlena.c | 4 +-
src/include/access/tupmacs.h | 51 ++++++++---
src/include/utils/arrayaccess.h | 25 ++++--
src/pl/plpython/plpy_typeio.c | 3 +-
10 files changed, 166 insertions(+), 119 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Nathan Bossart 2026-02-02 21:44:04 pgsql: test_shm_mq: Set background worker names.
Previous Message Tom Lane 2026-02-02 16:13:46 pgsql: In s_lock.h, use regular labels with %= instead of local labels.