Re: Big 7.1 open items

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
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 03:35:21
Message-ID: 3238.961126521@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"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". 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?

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.

I'd be interested to know what sort of facilities Oracle
provides for managing huge tables...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-16 03:43:41 Re: Big 7.1 open items
Previous Message Hiroshi Inoue 2000-06-16 03:20:16 RE: Big 7.1 open items

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2000-06-16 03:43:41 Re: Big 7.1 open items
Previous Message Hiroshi Inoue 2000-06-16 03:20:16 RE: Big 7.1 open items