Re: Patch: fix lock contention for HASHHDR.mutex
От | Robert Haas |
---|---|
Тема | Re: Patch: fix lock contention for HASHHDR.mutex |
Дата | |
Msg-id | CA+Tgmobp1Dsk5M0UDjm91kCtt+LLJ+tTzs0nucw4Vw2ZfQx29w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch: fix lock contention for HASHHDR.mutex (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: Patch: fix lock contention for HASHHDR.mutex
|
Список | pgsql-hackers |
On Fri, Dec 18, 2015 at 8:46 AM, Teodor Sigaev <teodor@sigaev.ru> wrote: >> Oh, that's an interesting idea. I guess the problem is that if the >> freelist is unshared, then users might get an error that the lock >> table is full when some other partition still has elements remaining. > > Could we split one freelist in hash to NUM_LOCK_PARTITIONS freelists? > Each partition will have its own freelist and if freelist is empty then > partition should search an entry in freelists of other partitions. To > prevent concurrent access it's needed to add one LWLock to hash, each > partition should lock LWlock in share mode to work with its own freelist and > exclusive to work with other freelists. > > Actually, I'd like to improve all partitioned hashes instead of improve only > one case. Yeah. I'm not sure that should be an LWLock rather than a spinlock, but we can benchmark it both ways. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: