Re: Misaligned BufferDescriptors causing major performance problems on AMD

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <stark(at)mit(dot)edu>, Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Misaligned BufferDescriptors causing major performance problems on AMD
Date: 2015-01-28 15:39:46
Message-ID: CA+Tgmoba=8c=yeDNg2usMGYzy4LZ+redwhKyXVfPTNtv+PjFQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 28, 2015 at 10:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> On 2015-01-26 21:13:31 -0500, Robert Haas wrote:
>>> So maybe we should also do something like what LWLocks do, and make a
>>> union between the actual structure and an appropriate array of padding
>>> bytes - say either 64 or 128 of them.
>
>> Hm. That's a bit bigger patch. I'm inclined to just let it slide for the
>> moment. I still have plans to downsize some of sbufdesc's content (move
>> the io lock out) and move the content lwlock inline. Then we're not
>> going to have much choice but do this...
>
> 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. Accordingly, I vote against applying any patch that
> pretends to improve their alignment unless it also does something to
> ensure that the size is a power of 2. Any notational changes that are
> forced by that would be much better done in a patch that does only that
> than in a patch that also makes functional changes to the header contents.

I entirely agree.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-28 15:40:47 Re: Parallel Seq Scan
Previous Message Robert Haas 2015-01-28 15:38:56 Re: Parallel Seq Scan