On Thu, Oct 10, 2013 at 03:23:30PM +0200, Andres Freund wrote: > On 2013-10-10 08:59:47 -0400, Robert Haas wrote: > > On Tue, Oct 8, 2013 at 6:24 PM, Andres Freund <and...@2ndquadrant.com> > > wrote: > > > Do you have a better alternative? Making the computation unconditionally > > > 64bit will have a runtime overhead and adding a StaticAssert in the > > > existing macro doesn't work because we use it in array sizes where gcc > > > balks. > > > We could try using inline functions, but that's not going to be pretty > > > either. > > > > > > I don't really see that many further usecases that will align 64bit > > > values on 32bit platforms, so I think we're ok for now. > > > > I'd be inclined to make the computation unconditionally 64-bit. I > > doubt the speed penalty is enough to worry about, and I think we're > > going to have more and more cases where optimizing for 32-bit > > platforms is just not the right decision. > > MAXALIGN is used in several of PG's hottest functions in many > scenarios. att_align_nominal is used in slot_deform_tuple, > heap_deform_tuple, nocachegetattr, etc. So I don't think that's viable > yet. At least not with much more benefit than this...
Agreed. Besides performance, aligning a wider-than-pointer value is an unusual need; authors should think thrice before doing that. I might have even defined the MAXALIGN64 macro in xlog.c rather than a core header. Incidentally, why does MAXALIGN64 use unsigned math while MAXALIGN uses signed math? -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
