From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Subject: | RE: Big 7.1 open items |
Date: | 2000-06-16 05:35:21 |
Message-ID: | 000001bfd754$a9e44f80$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-06-16 05:36:04 | Re: Big 7.1 open items |
Previous Message | The Hermit Hacker | 2000-06-16 04:01:05 | Re: postgresql.org ftp troubles? |
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 2000-06-16 05:36:04 | Re: Big 7.1 open items |
Previous Message | Tom Lane | 2000-06-16 04:57:00 | Re: coalesce view error |