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

From Hannu Krosing
Subject Re: making relfilenodes 56 bits
Date
Msg-id CAMT0RQTEgfGur6HbR5hNAe9QtBfoSraJYYNTH_Y-s2wsFRuc+Q@mail.gmail.com
Whole thread Raw
In response to Re: making relfilenodes 56 bits  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making relfilenodes 56 bits
List pgsql-hackers
Re: staticAssertStmt(MAX_FORKNUM <= INT8_MAX);

Have you really thought through making the ForkNum 8-bit ?

For example this would limit a columnar storage with each column
stored in it's own fork (which I'd say is not entirely unreasonable)
to having just about ~250 columns.

And there can easily be other use cases where we do not want to limit
number of forks so much

Cheers
Hannu

On Tue, Jul 12, 2022 at 10:36 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jul 12, 2022 at 1:09 PM Andres Freund <andres@anarazel.de> wrote:
> > What does currently happen if we exceed that?
>
> elog
>
> > > diff --git a/src/include/utils/wait_event.h b/src/include/utils/wait_event.h
> > > index b578e2ec75..5d3775ccde 100644
> > > --- a/src/include/utils/wait_event.h
> > > +++ b/src/include/utils/wait_event.h
> > > @@ -193,7 +193,7 @@ typedef enum
> > >       WAIT_EVENT_LOGICAL_REWRITE_TRUNCATE,
> > >       WAIT_EVENT_LOGICAL_REWRITE_WRITE,
> > >       WAIT_EVENT_RELATION_MAP_READ,
> > > -     WAIT_EVENT_RELATION_MAP_SYNC,
> > > +     WAIT_EVENT_RELATION_MAP_RENAME,
> >
> > Very minor nitpick: To me REPLACE would be a bit more accurate than RENAME,
> > since it includes fsync etc?
>
> Sure, I had it that way for a while and changed it at the last minute.
> I can change it back.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
>



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Zhihong Yu
Date:
Subject: Re: should check interrupts in BuildRelationExtStatistics ?