From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Shawn Debnath <sdn(at)amazon(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Drop type "smgr"? |
Date: | 2019-02-28 18:24:16 |
Message-ID: | 20190228182416.mqah6o6yqsok2f2y@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-02-28 13:16:02 -0500, Tom Lane wrote:
> Shawn Debnath <sdn(at)amazon(dot)com> writes:
> > On Thu, Feb 28, 2019 at 10:35:50AM -0500, Robert Haas wrote:
> >> Also, I don't see why we'd need a fake pg_database row in the first
> >> place. IIUC, the OID counter wraps around to FirstNormalObjectId, so
> >> nobody should have a database with an OID less than that value.
>
> > We have scripts under catalog directory that can check to ensure OIDs
> > aren't re-used accidentally. However, we still have to define an entry
> > in a catalog somewhere and I was proposing creating a new one,
> > pg_storage_managers?, to track these entries.
>
> That would fail to capture the property that the smgr OIDs mustn't
> conflict with database OIDs, so the whole thing still seems like an
> ugly kluge from here.
It's definitely a kludge, but it doesn't seem that bad for now. Delaying
a nice answer till we have a more efficient bufmgr representation
doesn't seem crazy to me.
I don't think there's a real conflict risk given that we don't allow for
duplicated oids across catalogs at bootstrap time, and this is
definitely a bootstrap time issue.
> > 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.
> 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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-02-28 18:25:20 | Re: plpgsql variable named as SQL keyword |
Previous Message | Mahendra Singh | 2019-02-28 18:22:47 | Re: Question about pg_upgrade from 9.2 to X.X |