Re: Restructured Shared Buffer Hash Table

On Tue, Aug 11, 2026 at 10:50 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
...

> My higher level problems with the current architecture of the buffer mapping
> infrastructure are the following:
>
>...
> 2) I think any buffer mapping lookup datastructure with 20 byte keys is going
> to considerably not great for performance.
>
...
...
> For 1-3), I think we should move towards a two-layer datastructure:
>
>
> a) a mapping from relation+fork to a per-"logical file" datastructure
>
> Keyed by database, tablespace, relfilenode, fork (although the fork
> could be handled differently).
>
> This lookup would be cached somewhere below Relation, so we only would need
> to occasionally do it, so the size of the key would not matter for
> performance.
>
> This addresses 1+2.
>
> (there's plenty complexity here, don't get me wrong)

Maybe a higher-level solution could be in order here, like allocating
a cluster-wide (i.e postmaster-wide) global oid at object creation
(and assign new ones after create database via copy) and just use that
?

As you said, the fork may be keyed differently, but if we accept the
global object count rduction from 4 billion to 256 million we could
use 4 bits of the global oid to encode the fork nr.

This would move all the complexity of generating the (database,
tablespace, relfilenode, fork) -> id mapping to table ceation time and
later it would just sit there and be always available