On 2015-01-28 10:58:40 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2015-01-28 10:35:28 -0500, Tom Lane wrote:
> >> Even if you didn't have plans like that, it would be entire folly to
> >> imagine that buffer headers will be exactly 64 bytes without some forcing
> >> function for that.
>
> > Meh. The 128 byte additionally used by the alignment don't hurt in any
> > case. But forcing all buffer descriptors to 64bit on a 32bit platform
> > isn't guaranteed to be performance neutral.
>
> > So, no I don't think it's a "folly" to do so.
>
> Once we have the mechanism in place, it is a policy decision whether to
> apply it on 32-bit builds. If you don't think there is evidence to
> support aligning headers on 32-bit builds, we don't have to do that.
I just have no idea whether it'd be beneficial to use more space on
32bit to pad the individual entries. Since this mostly is beneficial on
multi-socket, highly concurrent workloads, I doubt it really matter.
> But I firmly object to applying a patch that claims to align the headers
> on 64-bit platforms unless it includes something to ensure that it
> *actually* does that, regardless of platform variations or subsequent
> additions or subtractions of fields.
Well, the patch claims to align the buffer descriptor *array* not the
individual descriptors...
I personally still think that a comment above sbufdesc's definition
would be sufficient for now. But whatever. I'll enforce 64byte padding
on 64bit platforms, and do nothing on 32bit platforms.
> I think that's a necessary component
> of any such patch and should not be allowed to slide. If you don't want
> to do that work now, then drop the topic until you do.
Man. This style of comment really is just sad.
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services