Re: Big 7.1 open items - Mailing list pgsql-hackers

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Agreed.  Seems we have several issues:

>     filename contents
>     tablespace implementation
>     tablespace directory layout
>     tablespace commands and syntax

I think we've agreed that the filename must depend on tablespace,
file version, and file segment number in some fashion --- plus
the table name/OID of course.  Although there's no real consensus
about exactly how to construct the name, agreeing on the components
is still a positive step.

A couple of other areas of contention were:
revising smgr interface to be cleanerexactly what to store in pg_class

I don't think there's any quibble about the idea of cleaning up smgr,
but we don't have a complete proposal on the table yet either.

As for the pg_class issue, I still favor storing(a) OID of tablespace --- not for file access, but so that
associatedtablespace-table entry can be looked up    by tablespace management operations(b) pathname of file as a
columnof type "name", including           a %d to be replaced by segment #
 

I think Peter was holding out for storing purely numeric tablespace OID
and table version in pg_class and having a hardwired mapping to pathname
somewhere in smgr.  However, I think that doing it that way gains only
micro-efficiency compared to passing a "name" around, while using the
name approach buys us flexibility that's needed for at least some of
the variants under discussion.  Given that the exact filename contents
are still so contentious, I think it'd be a bad idea to pick an
implementation that doesn't allow some leeway as to what the filename
will be.  A name also has the advantage that it is a single item that
can be used to identify the table to smgr, which will help in cleaning
up the smgr interface.

As for tablespace layout/implementation, the only real proposal I've
heard is that there be a subdirectory of the database directory for each
tablespace, and that that have a subdirectory for each segment (extent)
of its tables --- where any of these subdirectories could be symlinks
off to a different filesystem.  Some unhappiness was raised about
depending on symlinks for this function, but I didn't hear one single
concrete reason not to do it, nor an alternative design.  Unless someone
comes up with a counterproposal, I think that that's what the actual
access mechanism will look like.  We still need to talk about what we
want to store in the SQL-level representation of a tablespace, and what
sort of tablespace management tools/commands are needed.  (Although
"try to make it look like Oracle" seems to be pretty much the consensus
for the command level, not all of us know exactly what that means...)

Comments?  Anything else that we do have consensus on?
        regards, tom lane