Re: Get rid of WALBufMappingLock - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: Get rid of WALBufMappingLock
Date
Msg-id f1782bc6-7435-4225-ac18-e6a865621f2b@postgrespro.ru
Whole thread Raw
In response to Re: Get rid of WALBufMappingLock  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
Good day, Tomas

14.03.2025 17:30, Tomas Vondra wrote:
> 
> Yes, with tmpfs the impact looks much more significant. For 8K the
> speedup is ~1.3x, for 64K it's up to ~2x, for 1M it's ~1.1x.
> 
> 
> That being said, I wonder how big is the impact for practical workloads.
> ISTM this workload is pretty narrow / extreme, it'd be much easier if we
> had an example of a more realistic workload, benefiting from this. Of
> course, it may be the case that there are multiple related bottlenecks,
> and we'd need to fix all of them - in which case it'd be silly to block
> the improvements on the grounds that it alone does not help.

Yes, I found this bottleneck when I did experiments with increasing
NUM_XLOGINSERT_LOCKS [1]. For this patch to be more valuable, there should
be more parallel xlog inserters.

That is why I initially paired this patch with patch that reduces
contention on WALInsertLocks ("0002-Several attempts to lock
WALInsertLock", last version at [2]).

Certainly, largest bottleneck is WALWriteLock around writting buffers and
especially fsync-ing them after write. But this intermediate bottleneck of
WALBufMappingLock is also worth to be removed.

[1]
https://postgr.es/m/flat/3b11fdc2-9793-403d-b3d4-67ff9a00d447%40postgrespro.ru
[2] https://postgr.es/m/c31158a3-7c26-4b26-90df-2df8f7bbe736%40postgrespro.ru

-------
regards
Yura Sokolov aka funny-falcon



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Allow default \watch interval in psql to be configured
Next
From: Nisha Moond
Date:
Subject: Re: Conflict detection for multiple_unique_conflicts in logical replication