On Mon, Dec 29, 2014 at 6:48 PM, Andres Freund <and...@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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
