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

Поиск
Список
Период
Сортировка
От Mengxing Liu
Тема [HACKERS] [GSOC][weekly report 5] Eliminate O(N^2) scaling from rw-conflicttracking in serializable transactions
Дата
Msg-id 56f0a8b5.1e4ce.15d28378ccf.Coremail.liu-mx15@mails.tsinghua.edu.cn
обсуждение исходный текст
Список pgsql-hackers
Sorry for report late. Our lab's machines crashed for several days. 

As I reported in the last email,
 https://www.postgresql.org/message-id/5b6b452.16851.15cf1ec010e.Coremail.liu-mx15@mails.tsinghua.edu.cn
I tried to decrease the contention on SerializableFinishedListLock. 
It works actually.  But I don't know why my optimization results in another problems: more contention on PREDICATELOCK_MANAGER_LWLOCK.

Here is the result of statistics collector. There were 36 connections in all, so most of them are waiting for locks. 
 (benchmark is ssibench, but other benchmarks have the same result) 

Original:
        SerializableXactHashLock, 0.36
        predicate_lock_manager, 6.00
        wal_insert, 0.07
        Se rializableFinishedListLock, 16.50

After optimization: 
        SerializableXactHashLock, 0.35
        predicate_lock_manager, 11.53
        buffer_content, 0.12
        SerializableFinishedListLock, 11.47

So in the end, the performance did not change obviously. 
Even if I enlarged the number of predicate locks (NUM_PREDICATELOCK_PARTITIONS) from 16 to 1024, 
there were still so many contentions. 

It bothered me for several days. The patch is attached. 
To focus on this issue, I removed other parts of modification. 
Do you have any advices for this ? 


--
Sincerely

Mengxing Liu





Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PATCH] Minor typo in the source repository documentation
Следующее
От: Victor Drobny
Дата:
Сообщение: [HACKERS] Authentification method on client side checking