From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Contention preventing locking |
Date: | 2018-02-20 16:39:48 |
Message-ID: | CANP8+j+Dy0m-Vj10bwX3Ah_2eYVd_0dJ_55=Ae7Wxwky7crtyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20 February 2018 at 16:07, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2018-02-20 17:04:15 | Re: Contention preventing locking |
Previous Message | Konstantin Knizhnik | 2018-02-20 16:07:53 | Re: Contention preventing locking |