From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Shawn Debnath <sdn(at)amazon(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Drop type "smgr"? |
Date: | 2019-02-28 22:08:49 |
Message-ID: | 20190228220849.qloxwix54mhzeqqg@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-03-01 09:48:33 +1300, Thomas Munro wrote:
> On Fri, Mar 1, 2019 at 7:24 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> > > Shawn Debnath <sdn(at)amazon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-02-28 22:17:43 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |
Previous Message | Tom Lane | 2019-02-28 21:49:31 | Re: POC: converting Lists into arrays |