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

Поиск
Список
Период
Сортировка
От Mengxing Liu
Тема [HACKERS] [GSOC][weekly report 8] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Дата
Msg-id 382f2a1b.2543.15d946bc112.Coremail.liu-mx15@mails.tsinghua.edu.cn
обсуждение исходный текст
Список 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





Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Mengxing Liu"
Дата:
Сообщение: Re: [HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Следующее
От: "Tels"
Дата:
Сообщение: Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?