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

From Mengxing Liu
Subject [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Date
Msg-id 18ace150.e338.15cc3a03133.Coremail.liu-mx15@mails.tsinghua.edu.cn
Whole thread Raw
Responses Re: [HACKERS] [GSOC][weekly report 3] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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





Attachment

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Broken hint bits (freeze)
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] REPLICA IDENTITY FULL