RE: Big 7.1 open items

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

In response to

Browse pgsql-hackers by date

  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?

Browse pgsql-patches by date

  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