On Tue, Aug 11, 2026 at 10:50 PM Andres Freund <[email protected]> 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
