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

From: "Mengxing Liu" <liu-mx15(at)mails(dot)tsinghua(dot)edu(dot)cn>
To: "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>, kgrittn <kgrittn(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Date: 2017-08-07 17:01:14
Message-ID: e9133e3.5a79.15dbda4b546.Coremail.liu-mx15@mails.tsinghua.edu.cn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 conflicts, 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 Content-Type Size
skip-list-for-conflict-tracking.patch application/octet-stream 11.9 KB
image/png 11.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-08-07 17:19:06 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Previous Message Peter Geoghegan 2017-08-07 16:25:24 Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values