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.
Ancient POSTGRES had an extra argument like that and would say eg
smgropen(rd->rd_rel->relsmgr, rd), but in this new idea I think it'd
always be a constant or a value from a BufferTag, and the BufferTag
would have been set with a constant, since the code reading these
buffers would always be code that knows which it wants. We'd be using
this new argument not as a modifier to control storage location as
they did back then, but rather as a whole new namespace for
RelFileNode values, that also happens to be stored differently; that
might be a hint that it could also go into RelFileNode (but I'm not
suggesting that).
> > 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.
--
Thomas Munro
https://enterprisedb.com