[HACKERS] [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions - Mailing list pgsql-hackers

From Mengxing Liu
Subject [HACKERS] [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Date
Msg-id e9133e3.5a79.15dbda4b546.Coremail.liu-mx15@mails.tsinghua.edu.cn
Whole thread Raw
Responses [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
In the last week, I focus on:

1) Continuing on optimization of skip list. Here is the new logic:
At first, I use an unordered linked list to do all inserting/searching operations.
When the number of conflicts is more than the threshold, transform the linked list into an ordered skip list.
Then all inserting/searching operations are done by the skip list.
By this way, for transactions with only a few conflicts, overhead of inserting is O(1). 
the patch is attached.

It helped a little, but just a little. In the end, the skip list has the same performance of the linked list.

2) Studying the performance of less contention on FinishedListLock. 
I found it can get benefit when the number of conflicts is medium. It is easy to understand the optimization 
has no influence when conflicts are too rare. But when there are too many c onflicts, partition lock
will be the new bottleneck and the performance can't be improved. A chart is attached. This optimization
can achieve 14% speedup at most. 

Do you think this optimization can be accepted?


--
Sincerely

Mengxing Liu





Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] free space % calculation in pgstathashindex
Next
From: Alvaro Herrera
Date:
Subject: [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions