Re: Restructured Shared Buffer Hash Table

From: Dhruv Aron <dhruv(dot)aron(at)gmail(dot)com>
To: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Restructured Shared Buffer Hash Table
Date: 2026-09-21 15:13:37
Message-ID: CAAStW3+5R35o_OOOmZcGShLK_s=wGnRJ9e4vh77_ZOMVHzXX9g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Just logged into commitfest for the first time, perhaps that's why.
Can you try again?

[image: image.png]

Best,
Dhruv Aron

On Mon, Sep 21, 2026 at 4:56 AM Alexandre Felipe <
o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:

> Hello,
>
> I want to create a commit fest entry for this, but I can't find Dhruv Aron
> there.
>
> [image: image.png]
>
> On Mon, Sep 14, 2026 at 7:34 PM Alexandre Felipe <
> o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:
>
>> v4.0 is not so fancy, but it works.
>>
>> No apparent bugs on this version, passing check-world [1]
>> The best test to stress this feature is in the recovery suite [2]
>> The main open question is whether we should add a second attempt if we
>> have
>> a lookup miss and the partition is locked (who knows it was locked by
>> someone
>> inserting the tag we want).
>>
>> I am curious to see the results of this with some real pgbench. So I
>> would be
>> grateful if some of you can stress that out.
>>
>> This version keeps the lock for insertion (and deletions), on the first
>> failure at
>> lookup, it acquires a LW_SHARED there too. These failures are very rare
>> so the impact of that lock in performance should be negligible compared to
>> acquiring the lock for every lookup.
>>
>> Not having to acquire a lock on its own can make the buffer lookup faster
>> (buffer hits).
>>
>> I am pasting three tables from my own benchmarks, from which I would like
>> to highlight a few results.
>> LWLockAcquire, LWLockRelease (nothing in between)
>> Uncontended with 10 workers: 218ns
>> Contended with 10 workers : 555 microseconds in one run 1.03ms in the
>> other
>>
>> Notice that the average is above q3 (0.57 quantile), indicating that it
>> is very
>> skewed, it is fast, but when it gets slow it becomes very slow. And this
>> is
>> precisely what I have seen with LWLock BufferMapping waits, they either
>> don't show up, or they take the cluster down (I am not a DBA, so it is
>> anecdotal
>> evidence).
>>
>>
>> Average uncontended hit and miss.
>> 2 workers, with lock (36, 38)
>> 10 workers, with lock (225,409)
>> 10 workers, without lock (156,252)
>>
>>
>>
>> workers | op / wait | avg | q1 | med | q3 | count
>> ---------+------------+---------+---------+---------+---------+--------
>> 2 | delete / 0 | 42.58 | 39.76 | 42.28 | 44.28 | 127999
>> 2 | delete / 1 | 5625.00 | 5625.00 | 5625.00 | 5625.00 | 1
>> 2 | hit / 0 | 36.01 | 33.86 | 35.81 | 37.77 | 128000
>> 2 | insert / 0 | 36.59 | 35.11 | 36.47 | 38.41 | 128000
>> 2 | LWLock / 0 | 35.59 | 33.23 | 35.17 | 37.14 | 128000
>> 2 | miss / 0 | 37.63 | 35.78 | 37.72 | 39.09 | 128000
>>
>>
>>
>> workers | op / wait | avg | q1 | med | q3 |
>> count
>>
>> ---------+------------+------------+-----------+-----------+------------+--------
>> 10 | delete / 0 | 792.11 | 166.58 | 225.58 | 277.75 |
>> 119522
>> 10 | delete / 1 | 1844238.60 | 45823.00 | 470479.00 | 2568042.25 |
>> 478
>> 10 | hit / 0 | 224.66 | 76.42 | 121.50 | 187.42 |
>> 120000
>> 10 | insert / 0 | 952.21 | 104.25 | 180.58 | 246.42 |
>> 119566
>> 10 | insert / 1 | 2154981.29 | 76708.00 | 703666.00 | 3334916.00 |
>> 434
>> 10 | LWLock / 0 | 218.06 | 69.33 | 104.17 | 152.67 |
>> 119987
>> 10 | LWLock / 1 | 1029929.62 | 126708.00 | 488459.00 | 836708.00 |
>> 13
>> 10 | miss / 0 | 408.87 | 76.42 | 156.08 | 184.00 |
>> 120000
>>
>> workers | op / wait | avg | q1 | med | q3 |
>> count
>>
>> ---------+------------+------------+-----------+-----------+------------+--------
>> 10 | delete / 0 | 628.94 | 166.58 | 236.08 | 291.85 |
>> 119595
>> 10 | delete / 1 | 2135859.85 | 80125.00 | 704750.00 | 3329688.00 |
>> 405
>> 10 | hit / 0 | 155.96 | 55.33 | 104.17 | 145.67 |
>> 120000
>> 10 | insert / 0 | 792.89 | 100.67 | 190.83 | 250.00 |
>> 119634
>> 10 | insert / 1 | 2272327.08 | 114083.00 | 666959.00 | 3580042.00 |
>> 366
>> 10 | LWLock / 0 | 305.68 | 69.50 | 107.58 | 159.75 |
>> 119993
>> 10 | LWLock / 1 | 555255.86 | 77437.50 | 390458.00 | 528979.50 |
>> 7
>> 10 | miss / 0 | 251.58 | 45.25 | 93.83 | 121.58 |
>> 120000
>>
>>
>> 1. With './configure' '--prefix' ... '--without-icu'
>> '--without-readline' '--enable-tap-tests' --enable-cassert && make -j -s
>> clean && make -j -s && make check-world
>> 2. make -C src/test/recovery check PROVE_TESTS="t/027_stream_regress.pl"
>>
>> PS.: I nearly forgot to attach the patches 🤣
>>
>>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-09-21 15:21:30 Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Previous Message Andres Freund 2026-09-21 15:09:35 Re: aio: worker: Free SMGR objects when idle