Re: Misaligned BufferDescriptors causing major performance problems on AMD - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Misaligned BufferDescriptors causing major performance problems on AMD
Date
Msg-id CA+TgmoZ0WUCh2x0WzVP-svWe4JKLaEPV0PUU81EO_4uYmK=6bA@mail.gmail.com
Whole thread Raw
In response to Re: Misaligned BufferDescriptors causing major performance problems on AMD  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Misaligned BufferDescriptors causing major performance problems on AMD  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Wed, Feb 5, 2014 at 11:37 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-02-05 11:23:29 -0500, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>> > And I think somebody already thought about it (c.f. ALIGNOF_BUFFER), it
>> > just wasn't updated in the last 10 years.
>>
>> No, ALIGNOF_BUFFER is there because we read something that said that I/O
>> transfers between userspace and kernel disk cache would be faster with
>> aligned buffers.  There's been no particular thought given to alignment
>> of other data structures, AFAIR.
>
> But it's not aligned anymore on at last half a decade's hardware, and
> it's what we already align *all* bigger ShmemAlloc() values with. And
> BufferDescriptors surely counts as larger in its entirety.
>
>> It may well be that your proposal is spot on.  But I'd like to see some
>> data-structure-by-data-structure measurements, rather than assuming that
>> alignment must be a good thing.
>
> I am fine with just aligning BufferDescriptors properly. That has
> clearly shown massive improvements.

I thought your previous idea of increasing BUFFERALIGN to 64 bytes had
a lot to recommend it.  But that doesn't mean it doesn't need testing.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: jsonb and nested hstore
Next
From: Robert Haas
Date:
Subject: Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication