Re: [PATCH] Refactoring of LWLock tranches - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [PATCH] Refactoring of LWLock tranches
Date
Msg-id 20160105152825.GC31334@momjian.us
Whole thread Raw
In response to Re: [PATCH] Refactoring of LWLock tranches  ("andres@anarazel.de" <andres@anarazel.de>)
Responses Re: [PATCH] Refactoring of LWLock tranches  ("andres@anarazel.de" <andres@anarazel.de>)
List pgsql-hackers
On Sun, Dec 13, 2015 at 12:35:34PM +0100, Andres Freund wrote:
> > > One thing to call out is that an "oversized" s_lock can now make
> > > BufferDesc exceed 64 bytes, right now that's just the case when it's
> > > larger than 4 bytes.  I'm not sure if that's cause for real concern,
> > > given that it's not very concurrent or ancient platforms where that's
> > > the case.
> > > http://archives.postgresql.org/message-id/20150915020625.GI9666%40alap3.anarazel.de
> > > would alleviate that concern again, as it collapses flags, usage_count,
> > > buf_hdr_lock and refcount into one 32 bit int...
> > 
> > I don't think that would be worth worrying about even if we didn't
> > have a plan in mind that would make it go away again, and even less so
> > given that we do have such a plan.
> 
> Ok cool. I'm not particularly concerned either, just didn't want to slip
> that in without having it called out.

Uh, didn't you and I work in 9.5 to make sure the BufferDesc was 64-byte
aligned to avoid double-CPU cache invalidation that was causing
performance problems on a server you were testing?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription                             +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Building pg_xlogdump reproducibly
Next
From: "andres@anarazel.de"
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches