On 20.02.2018 19:39, Simon Riggs wrote:
On 20 February 2018 at 16:07, Konstantin Knizhnik
<k.knizh...@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.
So, if I correctly understand the primary goal of setting tuple lock in
heapam.c is to avoid contention caused
by concurrent release of all waiters.
But my transaction lock chaining patch eliminates this problem in other way.
So what about combining your patch (do not lock Snapshot.xmax) + with my
xlock patch and ... completely eliminate tuple lock in heapam?
In this case update of tuple will require obtaining just one heavy
weight lock.
I made such experiment and didn't find any synchronization problems with
my pgrw test.
Performance is almost the same as with vanilla+xlock patch:
https://docs.google.com/spreadsheets/d/1QOYfUehy8U3sdasMjGnPGQJY8JiRfZmlS64YRBM0YTo/edit?usp=sharing
I wonder why instead of chaining transaction locks (which can be done
quite easily) approach with extra tuple lock was chosen?
May be I missed something?
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
