On Fri, Mar 1, 2019 at 7:24 AM Andres Freund <and...@anarazel.de> wrote: > On 2019-02-28 13:16:02 -0500, Tom Lane wrote: > > Shawn Debnath <s...@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
