Re: LWLocks in DSM memory
От | Robert Haas |
---|---|
Тема | Re: LWLocks in DSM memory |
Дата | |
Msg-id | CA+TgmoYQ7oYJ9ekcL1zPx1JeJi8TLGPTOEUXWxYkG_cP9GX6FQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LWLocks in DSM memory (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: LWLocks in DSM memory
|
Список | pgsql-hackers |
On Thu, Jul 28, 2016 at 12:12 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund <andres@anarazel.de> wrote: >> I think the better fix here would acutally be to get rid of a pointer >> based list here, and a) replace the queue with integer offsets ... > > Here is a prototype of that idea. It replaces that dlist with a > proclist, a new specialised doubly-linked list for pgprocno values, > using INVALID_PGPROCNO for termination. It works with proclist_node > objects inside PGPROC at an arbitrary offset which must be provided > when you initialise the proclist. Aside from the fact that this allows LWLocks inside DSM segments, which I definitely want to support, this seems to have the nice property of reducing the size of an LWLock by 8 bytes. We need to consider what to do about LWLOCK_MINIMAL_SIZE. We could (a) decide to still pad all arrays of LWLocks to 32 bytes per LWLock so as to reduce false sharing, and rename this constant not to imply minimality; or (b) alter the macro definition to allow for 16 bytes as a possible result. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: