On 2015-01-01 11:55:03 -0500, Robert Haas wrote:
> On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> Andres reported the above 2x pgbench difference in February, but no
> >> action was taken as everyone felt there needed to be more performance
> >> testing, but it never happened:
> >
> > FWIW, I have no idea what exactly should be tested there. Right now I
> > think what we should do is to remove the BUFFERALIGN from shmem.c and
> > instead add explicit alignment code in a couple callers
> > (BufferDescriptors/Blocks, proc.c stuff).
>
> That seems like a strange approach. I think it's pretty sensible to
> try to ensure that allocated blocks of shared memory have decent
> alignment, and we don't have enough of them for aligning on 64-byte
> boundaries (or even 128-byte boundaries, perhaps) to eat up any
> meaningful amount of memory. The BUFFERALIGN() stuff, like much else
> about the way we manage shared memory, has also made its way into the
> dynamic-shared-memory code. So if we do adjust the alignment that we
> guarantee for the main shared memory segment, we should perhaps adjust
> DSM to match. But I guess I don't understand why you'd want to do it
> that way.
The problem is that just aligning the main allocation to some boundary
doesn't mean the hot part of the allocation is properly aligned. shmem.c
in fact can't really do much about that - so fully moving the
responsibility seems more likely to ensure that future code thinks about
alignment.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services