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

Поиск
Список
Период
Сортировка
От Mengxing Liu
Тема [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Дата
Msg-id 18ace150.e338.15cc3a03133.Coremail.liu-mx15@mails.tsinghua.edu.cn
обсуждение исходный текст
Ответы Re: [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Hi, all. In the last week, I fixed some bugs and replace the list of “PossibleUnsafeConflicts” with hash table.
It passed the existing 178 tests. The patch is attached.

But in my benchmark, the throughput decrease by 15% after the modification.
Can you help me do a quick review to find if there is anything wrong?
I also attached the flame graph before/after the modification for reference.

Here is my questions:
1. Is there any function in HTAB like “clear” that can make itself empty quickly?
In this patch, when releasing a transaction object, I need to scan the hash table and
use “hash_search” to remove entries one by one. It would make releasing operation slower.

In a previous email, I reported that many backends wait for the lock “SerializableFinishedListLock”;
If we don't implement functions like “ReleaseOneSerializableXact” quickly, they will be the bottleneck.

2. Is the HTAB thread-safe? I would focus on removing some unnecessary locks if possible. 

My plan for the next:
I will add a TPC-B benchmark to represent classic OLTP benchmark.


--
Sincerely

Mengxing Liu





Вложения

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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Broken hint bits (freeze)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] REPLICA IDENTITY FULL