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+postg...@gmail.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
