Re: Contention preventing locking
От | Simon Riggs |
---|---|
Тема | Re: Contention preventing locking |
Дата | |
Msg-id | CANP8+j+Dy0m-Vj10bwX3Ah_2eYVd_0dJ_55=Ae7Wxwky7crtyw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Contention preventing locking (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: Contention preventing locking
|
Список | pgsql-hackers |
On 20 February 2018 at 16:07, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote: > > > On 20.02.2018 14:26, Simon Riggs wrote: >> >> Try locking the root tid rather than the TID, that is at least unique >> per page for a chain of tuples, just harder to locate. >> > As far as I understand, it is necessary to traverse the whole page to locate > root tuple, isn't it? > If so, then I expect it to be too expensive operation. Scanning the whole > page on tuple update seems to be not an acceptable solution. Probably. It occurs to me that you can lock the root tid in index_fetch_heap(). I hear other DBMS lock via the index. However, anything you do with tuple locking could interact badly with heap_update and the various lock modes, so be careful. You also have contention for heap_page_prune_opt() and with SELECTs to consider, so I think you need to look at both page and tuple locking. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: