Re: [PATCH] Refactoring of LWLock tranches
От | Bruce Momjian |
---|---|
Тема | Re: [PATCH] Refactoring of LWLock tranches |
Дата | |
Msg-id | 20160105152825.GC31334@momjian.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Refactoring of LWLock tranches ("andres@anarazel.de" <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Refactoring of LWLock tranches
|
Список | 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 по дате отправления: