pgsql: Refactor att_align_nominal() to improve performance. - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Refactor att_align_nominal() to improve performance.
Date
Msg-id E1vmzmC-000mMJ-2J@gemulon.postgresql.org
Whole thread Raw
List 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(-)


pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: pgsql: In s_lock.h, use regular labels with %= instead of local labels.
Next
From: Nathan Bossart
Date:
Subject: pgsql: test_shm_mq: Set background worker names.