Hi,
Thanks for the patch. Looks like a decent improvement.
On 2026-01-28 20:20:24 -0500, Tom Lane wrote:
> One of the concerns that prevented this from being done long
> ago was not wanting to add overhead to tuple forming/deforming.
> However that concern seems gone now, because we map TYPALIGN_xxx
> values to numeric alignments in populate_compact_attribute()
> which is not so performance-critical. It might be worth
> worrying about the increased cost of att_align_nominal(),
> but that macro is not that heavily used IMO.
Yea, it shouldn't matter too much these days. We might want to verify that
the array code isn't overly affected, e.g. array_iter_next() was deemed perf
critical enough by someone to make it an inline function. I don't know if the
compiler is somehow smart enough to move the conditionals outside of a loop
over array_iter_next().
Perhaps we should make att_align_nominal() first determine the numerical
alignment value and then have it use TYPEALIGN()? I think that'd be more
likely to be pulled out of loops by the compile.
Perhaps it's time to reformat att_align_nominal() into an static inline? It's
pretty hard to read.
I don't love the 'l' for TYPALIGN_INT64, but I guess I don't really have a
better suggestion.
It wouldn't hurt to have a short SQL level test for creating a type with int8
& max alignments.
Greetings,
Andres Freund
