Re: Patch: fix lock contention for HASHHDR.mutex
От | Teodor Sigaev |
---|---|
Тема | Re: Patch: fix lock contention for HASHHDR.mutex |
Дата | |
Msg-id | 56740E41.4010708@sigaev.ru обсуждение исходный текст |
Ответ на | Re: Patch: fix lock contention for HASHHDR.mutex (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Patch: fix lock contention for HASHHDR.mutex
Re: Patch: fix lock contention for HASHHDR.mutex |
Список | pgsql-hackers |
> 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. -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
В списке pgsql-hackers по дате отправления: