On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> On Fri, Mar 1, 2019 at 7:24 AM Andres Freund <andres@anarazel.de> wrote:
> > On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > > Shawn Debnath <sdn@amazon.com> writes:
> > > > Another thought: my colleague Anton Shyrabokau suggested potentially
> > > > re-using forknumber to differentiate smgrs. We are using 32 bits to
> > > > map 5 entries today.
> > >
> > > Yeah, that seems like it might be a workable answer.
> >
> > Yea, if we just split that into two 16bit entries, there'd not be much
> > lost. Some mild mild performance regression due to more granular
> > memory->register reads/writes, but I can't even remotely see that
> > matter.
>
> Ok, that's a interesting way to include it in BufferTag without making
> it wider. But then how about the SMGR interface? I think that value
> would need to be added to the smgropen() interface, and all existing
> callers would pass in (say) SGMR_RELATION (meaning "use md.c"), and
> new code would use SMGR_UNDO, SMGR_SLRU etc. That seems OK to me.
Right, seems like we should do that independent of whether we end up
reusing the dboid or not.
> > > Since, per this discussion, the smgr IDs need not really be OIDs at
> > > all, we just need a few bits for them.
> >
> > Personally I find having them as oids more elegant than the distaste
> > from misusing the database oid for a wihle, but I think it's fair to
> > disagree here.
>
> It sounds like your buffer mapping redesign would completely change
> the economics and we could reconsider much of this later without too
> much drama; that was one of the things that made me feel that the
> magic database OID approach was acceptable at least in the short term.
Right.
FWIW, I think while distasteful, I could see us actually using oids,
just ones that are small enough to fit into 16bit...
Greetings,
Andres Freund
