Re: making relfilenodes 56 bits

On Tue, Jun 28, 2022 at 5:15 PM Simon Riggs
<simon(dot)riggs(at)enterprisedb(dot)com> wrote:
>
> 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.

Yeah this is possible but I am not seeing the clear advantage. Of
Course we can widen the RelFileNumber to 64 instead of 56 but with the
added complexity of storing the mapping. I am not sure if it is
really worth it?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com