Re: AW: Big 7.1 open items

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
>> I guess on similar reasoning I would suggest inserting the extent
>> subdirectory, because it would be easier to create different 
>> filesystems for them.
>> 
>> ln -s data/base/testdb/myspace/extent1 /var/myspace/extent1/testdb

> Grmpf, I meant:
>     ln -s /var/myspace/extent1/testdb data/base/testdb/myspace/extent1

That would mean more bookkeeping: everytime you add an extent to a
tablespace, you'd have to go around and find all the referencing
databases and add a symlink to each one.

But I think the direction we're headed in is that the data/base/DBNAME
directories are going to disappear entirely, so this argument about
what symlinks they need to have is a bit pointless ;-).  Databases
are going to become a higher-level concept that's not directly reflected
in the physical layout.

The way I'm currently envisioning it is that we have paths like
data/spaces/TABLESPACE/EXTENT/RELATION.VERSION

(ignoring the details about whether we use names or OIDs and which
directory levels might be symlinks).  Since we will require each logical
database to have a distinct "home tablespace" in which its system tables
live, that "home tablespace" can be the runtime working directory for
backends running in that database.  If you like you can think of the
home tablespace directory as being equivalent to the old database
directory, but it's really a different notion --- and in particular,
it's got nothing to do with how the backend addresses tables that are
in other tablespaces.

BTW, it occurs to me that we ought to have some frammish whereby temp
files and tables created by backends running in a particular database
can be directed to a different tablespace.  If we do nothing, then
they'd always appear in the database's home tablespace, but I can sure
see a dbadmin wanting to push his large sort temp files off to someplace
else...
        regards, tom lane