On Thu, Feb 28, 2019 at 7:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Thu, Feb 28, 2019 at 7:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I agree that smgrtype as it stands is pretty pointless, but what
> >> will we be using instead to get to those other implementations?
>
> > Our current thinking is that smgropen() should know how to map a small
> > number of special database OIDs to different smgr implementations
>
> Hmm. Maybe mapping based on tablespaces would be a better idea?
In the undo log proposal (about which more soon) we are using
tablespaces for their real purpose, so we need that OID. If you SET
undo_tablespaces = foo then future undo data created by your session
will be written there, which might be useful for putting that IO on
different storage. We also use the relation OID to chop up the undo
address space into separate numbered undo logs, so that different
sessions get their own space to insert data without trampling on each
other's buffer locks. That leaves only the database OID to mess with
(unless we widen buffer tags and the smgropen() interface).
> > Unlike the ancestral code, it wouldn't need to appear in
> > catalogs or ever be seen or typed in by users so there still wouldn't
> > be a use for this type.
>
> Yeah, the $64 problem at this level is that you don't really want
> to depend on catalog contents, because you cannot do a lookup to
> find out what to do.
Right. It would be a circular dependency if you had to read a catalog
before you could consult low level SLRUs like (say) the clog* via
shared buffers, since you need the clog to read the catalog, or (to
peer a long way down the road and around several corners) if the
catalogs themselves could optionally be stored in an undo-aware table
access manager like zheap, which might require reading undo. I think
this block storage stuff exists at a lower level than relations and
transactions and therefore also catalogs, and there will be a small
fixed number of them and it makes sense to hard-code the knowledge of
them.
*I'm at least a little bit aware of the history here: your 2001 commit
2589735d moved clog out of shared buffers! That enabled you to
develop the system of segment files truncated from the front. That's
sort of what this new smgr work is about; putting things in shared
buffers, but just mapping the blocks to paths differently than md.c,
as appropriate.
--
Thomas Munro
https://enterprisedb.com