Message-ID: <dbbd1998-19ff-4ac2-b4b1-a39f4ec1b0f5@iki.fi>
Date: Tue, 7 Jul 2026 22:13:48 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Restructured Shared Buffer Hash Table
To: Dhruv Aron <dhruv.aron@gmail.com>, pgsql-hackers@postgresql.org
Cc: haoyu.huang.68@gmail.com
References: 
 <CAAStW3JX_7LcCD1U+89vyMmLreDs0XsBU-JDdFf5PD_Woy1pag@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAAStW3JX_7LcCD1U+89vyMmLreDs0XsBU-JDdFf5PD_Woy1pag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/dbbd1998-19ff-4ac2-b4b1-a39f4ec1b0f5%40iki.fi>
Precedence: bulk

On 07/07/2026 21:41, Dhruv Aron wrote:
> At Databricks, we’ve found that the existing dynahash table structure is 
> leaving performance gains on the table when it comes to shared buffer 
> lookups: the multi-level structure (directory, segment, bucket chain, 
> freelist) appears excessive for the shared buffers and could be 
> simplified to boost performance and lower memory overhead. As such, we 
> are proposing a specialized hash table just for this purpose and would 
> appreciate feedback on this approach.

Yeah, the dynahash has features that we just don't need in the buffer 
lookup table...

The indirection with the directory is actually unnecessary for all the 
shared memory hash tables, since none of them can be resized. I've 
wondered if we should try to eliminate that from dynahash for all shmem 
hash tables. But the buffer lookup table is very performance-critical, 
so if there are any performance gains to be had, it's indeed probably 
worthwhile to have a separate implementation just for it.

> bufmgr.c also changed slightly to prevent a race condition. 

Hmm, we're now holding the buffer header lock much longer than before, 
in InvalidateBuffer(). It's a spinlock, it really should not be held for 
more than a few instructions. BufTableDelete() is very fast in the new 
implementation, but still. Could we perhaps do some of 
BufTableDelete()'s work ahead of time, before we acquire the buffer 
header lock? Or maybe it's not a problem, in which case some kind of a 
worst case scenario benchmark to show that would be nice. Maybe test how 
it behaves when you have a lot of hash collisions, I think that'd make 
BufTableDelete() more expensive.

> My testing 
> (helper script also attached) indicates that all three standard hash 
> table operations (insert, lookup, and delete) generally execute 
> significantly faster than the existing PG18 dynahash counterparts:

Nice!

I wonder how big the impact is with real world workloads. I've certainly 
seen the buffer table lookups consume a fair share of CPU time, so I'd 
assume that it shows up.


Another data point:

unpatched master, with shared_buffers='128 MB':

postgres=# select * from pg_shmem_allocations where name like 'Shared 
Buffer%' order by name ;
             name            |    off    |  size  | allocated_size
----------------------------+-----------+--------+----------------
  Shared Buffer Lookup Table | 141607040 | 926000 |         926108
(1 row)

With this patch:

postgres=# select * from pg_shmem_allocations where name like 'Shared 
Buffer%' order by name ;
              name             |    off    |  size  | allocated_size
------------------------------+-----------+--------+----------------
  Shared Buffer Lookup Buckets | 141607040 |  65536 |          65644
  Shared Buffer Lookup Entries | 141672576 | 393216 |         393216
(2 rows)

So the new hash table takes much less memory. That's nice because you 
can then fit more in CPU caches.

- Heikki