Re: making relfilenodes 56 bits

Hi,

On 2022-06-24 10:59:25 -0400, Robert Haas wrote:
> A preliminary refactoring that was discussed in the past and was
> originally in 0001 was to move the fields included in BufferTag via
> RelFileNode/Locator directly into the struct. I think maybe it doesn't
> make sense to include that in 0001 as you have it here, but maybe that
> could be 0002 with the main patch to follow as 0003, or something like
> that. I wonder if we can get by with redefining RelFileNode like this
> in 0002:
>
> typedef struct buftag
> {
> Oid spcOid;
> Oid dbOid;
> RelFileNumber fileNumber;
> ForkNumber forkNum;
> } BufferTag;

If we "inline" RelFileNumber, it's probably worth reorder the members so that
the most distinguishing elements come first, to make it quicker to detect hash
collisions. It shows up in profiles today...

I guess it should be blockNum, fileNumber, forkNumber, dbOid, spcOid? I think
as long as blockNum, fileNumber are first, the rest doesn't matter much.

> 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.

Greetings,

Andres Freund