Re: RFC: Packing the buffer lookup table

Hi,

On 2025-02-04 19:58:36 +0100, Matthias van de Meent wrote:
> On Thu, 30 Jan 2025 at 08:48, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> >
> > Together that results in the following prototype patchset.
>
> Here's an alternative patch, which replaces dynahash in the buffer
> lookup table with an open-coded replacement that has fewer
> indirections during lookups, and allows for a much increased locality.
>
> Overall, it has less memory usage than our current dynahash in all
> cases; but compared to my previous patch it improves memory only in
> some cases, in others it uses more memory.
>
> The main design is a separate chaining hash table (similar to and
> derived from code of Dynahash) to provide efficient access to free
> elements.

Why do you want to use a separate chaining hash table? For something as
performance sensitive as this the lower cache hit ratio seems like a strong
reason to not go for such a hash table "architecture"?

I think it'd be better to work towards not using a hash table for the buffer
mapping table than to write a dedicated hash table implementation for it
though. A hash table

a) doesn't have ordered access support, which causes a bunch of O(NBuffers)
operations and makes things like readahead etc way more expensive
b) doesn't benefit from spatial locality, even though buffer lookups have a
very high degree of spatial locality

Greetings,

Andres Freund