Re: making relfilenodes 56 bits - Mailing list pgsql-hackers

From Robert Haas
Subject Re: making relfilenodes 56 bits
Date
Msg-id CA+TgmoZte9YAonmQ-0x027+VxTK_dHpC2zp-KF-zE2WqQ-degQ@mail.gmail.com
Whole thread Raw
In response to Re: making relfilenodes 56 bits  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: making relfilenodes 56 bits  (Andres Freund <andres@anarazel.de>)
Re: making relfilenodes 56 bits  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Fri, Jun 24, 2022 at 7:08 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> I have changed that. PFA, the updated patch.

Apart from one minor nitpick (see below) I don't see a problem with
this in isolation. It seems like a pretty clean renaming. So I think
we need to move onto the question of how clean the rest of the patch
series looks with this as a base.

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;

And then like this in 0003:

typedef struct buftag
{
    Oid     spcOid;
    Oid     dbOid;
    RelFileNumber   fileNumber:56;
    ForkNumber  forkNum:8;
} BufferTag;

- * from catalog OIDs to filenode numbers.  Each database has a map file for
+ * from catalog OIDs to filenumber.  Each database has a map file for

should be filenumbers

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Pre-installed index access methods cannot be manually installed.
Next
From: Aleksander Alekseev
Date:
Subject: Re: Make COPY extendable in order to support Parquet and other formats