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:

Reply via email to