On 2019-03-01 09:48:33 +1300, Thomas Munro wrote: > 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.
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
