Re: Restructured Shared Buffer Hash Table

On Mon, Oct 12, 2026 at 1:40 PM Alexandre Felipe <
o(dot)alexandre(dot)felipe(at)gmail(dot)com> wrote:

> 1. mod vs bitwise and
> Instead of computing [hashcode % num_buckets] you could save
> bucket_mask = num_bucket - 1, and do hashcode & bucket_mask.
>
> 2. the 1.5 factor
> On my first review I pointed out that in one specific test for
> shared_buffers
> as a power of two the number of buckets in your patch ended up being half
> as many as the previous version (maybe that is the correct way to go).
> Or maybe you want at least to rewrite that line using integer arithmetic.
>

Regarding 1: Yes, the bitwise-AND should work and would most likely be more
performant than using modulo.
Regarding 2: Since the patched table does not allow inserting a new entry
before deleting the stale entry for the same slot, there was no need to
additionally allocate NUM_BUFFER_PARTITIONS buckets (the reason why the
number of buckets for the master code was rounded up to 0x8000 instead of
0x4000 for 128MB SB). Could you elaborate more on what you mean by
'[rewriting] that line using integer arithmetic?'

> 4. scalability
> In your 16 GB test the gains are minimal. What changes at that scale?
> That suggests that maybe the gain at 4 GB was due to a high cache hit
> (not a bad thing, but important to have it clear).
>

As you point out, the primary factor should be that larger sizes result in
higher cache hit rates, which boosts the mainstream buffer table's
performance closer to that of the patched code.

Best,
Dhruv