Re: making relfilenodes 56 bits

On Sat, 25 Jun 2022 at 02:30, Andres Freund <andres(at)anarazel(dot)de> wrote:

> > And then like this in 0003:
> >
> > typedef struct buftag
> > {
> > Oid spcOid;
> > Oid dbOid;
> > RelFileNumber fileNumber:56;
> > ForkNumber forkNum:8;
> > } BufferTag;
>
> Probably worth checking the generated code / the performance effects of using
> bitfields (vs manual maskery). I've seen some awful cases, but here it's at a
> byte boundary, so it might be ok.

Another approach would be to condense spcOid and dbOid into a single
4-byte Oid-like number, since in most cases they are associated with
each other, and not often many of them anyway. So this new number
would indicate both the database and the tablespace. I know that we
want to be able to make file changes without doing catalog lookups,
but since the number of combinations is usually 1, but even then, low,
it can be cached easily in a smgr array and included in the checkpoint
record (or nearby) for ease of use.

typedef struct buftag
{
Oid db_spcOid;
ForkNumber uint32;
RelFileNumber uint64;
} BufferTag;

That way we could just have a simple 64-bit RelFileNumber, without
restriction, and probably some spare bytes on the ForkNumber, if we
needed them later.

--
Simon Riggs http://www.EnterpriseDB.com/