On Mon, Sep 7, 2015 at 1:59 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers