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

From Mengxing Liu
Subject [HACKERS] [GSOC][weekly report 8] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Date
Msg-id 382f2a1b.2543.15d946bc112.Coremail.liu-mx15@mails.tsinghua.edu.cn
Whole thread Raw
List pgsql-hackers
In the last week, I focused on tuning the performance of skip list and fixed several bugs.
1. As only out-conflicts are checked in RWConflictExists, I removed all modification concerned with in-conflicts;
2. If the conflict list is too short, I inserted an item just like inserting into an ordered linked list, that is, 
comparing items existing in the list one by one to find the right position. Using skip list is slow when the list is short.
3. Not using the abstract skip list interface; I was afraid that it would bring a little overhead. But results showed that 
it had no influence. I will roll it back if necessary.

Sadly, The performance is not better than the original version.  But it's highest one among all efforts I did before.
It likes hash table. Tracking conflict is faster but inserting conflicts is slower.
In a quick test, cpu cycles consumed by two functions RWConflictExists/SetRWCon flict is as below.
RWConflictExistsSetRWConflict
linked list1.39%0.14%
skip list1.15%0.35%

According to the suggestions of Alvaro,  I'll give a detailed performance report tomorrow.

--
Sincerely

Mengxing Liu





Attachment

pgsql-hackers by date:

Previous
From: "Mengxing Liu"
Date:
Subject: Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Next
From: "Tels"
Date:
Subject: Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?