> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > Tablespace is an encapsulation of table allocation and the
> > name should be irrevant to the location basically. So above
> > seems very bad for me.
> > Anyway I don't see any advantage in fixed mapping impleme
> > ntation. After renewal,we should at least have a possibility to
> > allocate a specific table in arbitrary separate directory.
>
> Call a "directory" a "tablespace" and we're on the same page,
> aren't we? Actually I'd envision some kind of admin command
> "CREATE TABLESPACE foo AS /path/to/wherever".
Yes,I think 'tablespace -> directory' is the most natural
extension under current file_per_table storage manager.
If many_tables_in_a_file storage manager is introduced,we
may be able to change the definiiton of TABLESPACE
to 'tablespace -> files' like Oracle.
> That would make
> appropriate system catalog entries and also create a symlink
> from ".../data/base/foo" (or some such place) to the target
> directory.
> Then when we make a table in that tablespace,
> it's in the right place. Problem solved, no?
>
I don't like symlink for dbms data files. However it may
be OK,If symlink are limited to 'tablespace->directory'
corrspondence and all tablespaces(including default
etc) are symlink. It is simple and all debugging would
be processed under tablespace_is_symlink environment.
> It gets a little trickier if you want to be able to split
> multi-gig tables across several tablespaces, though, since
> you couldn't just append ".N" to the base table path in that
> scenario.
>
This seems to be not that easy to solve now.
Ross doesn't change this naming rule for multi-gig
tables either in his trial.
> I'd be interested to know what sort of facilities Oracle
> provides for managing huge tables...
>
In my knowledge about old Oracle,one TABLESPACE
could have many DATAFILEs which could contain
many tables.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp