On Mon, Sep 7, 2015 at 1:59 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-09-06 15:28:40 +0200, Andres Freund wrote:
>> Hm. I found that the buffer content lwlocks can actually also be a
>> significant source of contention - I'm not sure reducing padding for
>> those is going to be particularly nice. I think we should rather move
>> the *content* lock inline into the buffer descriptor. The io lock
>> doesn't matter and can be as small as possible.
>
> POC patch along those lines attached. This way the content locks have
> full 64byte alignment *without* any additional memory usage because
> buffer descriptors are already padded to 64bytes. I'd to reorder
> BufferDesc contents a bit and reduce the width of usagecount to 8bit
> (which is fine given that 5 is our highest value) to make enough room.
>
> I've experimented reducing the padding of the IO locks to nothing since
> they're not that often contended on the CPU level. But even on my laptop
> that lead to a noticeable regression for a readonly pgbench workload
> where the dataset fit into the OS page cache but not into s_b.
I like this approach, though I think clearly it needs more performance testing.
The method of determining the tranche IDs is totally awful, though. I
assume that's just a dirty hack for the POC and not something you'd
seriously consider doing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
