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
skip-list-for-conflict-tracking.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
