Re: Decoupling our alignment assumptions about int64 and double

Andres Freund <andres@anarazel.de> writes:
> Thanks for the patch.  Looks like a decent improvement.

Thanks for looking!

> On 2026-01-28 20:20:24 -0500, Tom Lane wrote:
>> ... It might be worth
>> worrying about the increased cost of att_align_nominal(),
>> but that macro is not that heavily used IMO.

> 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.

Yeah, I was thinking about actually breaking that into two source-code
steps, a function to map TYPALIGN_xxx to numeric alignment and then a
replacement for att_align_nominal that takes a numeric alignment.
If you think it's worth worrying about I'm happy to do that.

> Perhaps it's time to reformat att_align_nominal() into an static inline? It's
> pretty hard to read.

+1, I was not revisiting any of that for this draft, but if we're going
to refactor it then an inline function seems good.

> I don't love the 'l' for TYPALIGN_INT64, but I guess I don't really have a
> better suggestion.

Of course I was thinking 'l' for "long", but I agree it's not great
typographically.  One idea is 'L' not 'l', but that gives up
consistency for visual separation.  Any other ideas out there?

> It wouldn't hurt to have a short SQL level test for creating a type with int8
> & max alignments.

hmm ... yeah, I guess those code paths might not be covered already.

			regards, tom lane