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
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 |
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 |