Re: Big 7.1 open items

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <JanWieck@yahoo.com>, "Ross J. Reedstrom" <reedstrm@rice.edu>, Don Baccus <dhogaza@pacifier.com>, PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: 2000-06-20T13:40:03Z
Lists: pgsql-hackers
> > Yes, but is anyone suggesting a solution that does not work with
> > symlinks?  If not, why not do it that way?
> >
> 
> Maybe other solutions have been proposed already because
> there have been so many opinions and proposals.
> 
> I've felt TABLE(DATA)SPACE discussion has always been
> divergent.  IMHO,one of the main cause is that various factors
> have been discussed at once.  Shouldn't we make step by step
> consensus in TABLE(DATA)SPACE discussion ?
> 
> IMHO,the first step is to decide the syntax of CREATE TABLE
> command not to define TABLE(DATA)SPACE.
> 
> Comments ?

Agreed.  Seems we have several issues:

	filename contents
	tablespace implementation
	tablespace directory layout
	tablespace commands and syntax

Filename syntax seems to have resolved to
tablespace/tablename_oid_version or something like that.  I think a
clean solution to keep symlink names in sync with rename is to use hard
links during rename, and during vacuum, if the link count is greater
than one, we can scan the directory and remove old files matching the
oid.

I hope we can implement tablespaces using symlinks that can be dump, but
the symlink location does not have to be stored in the database.

Seems we are going to use Extent-2/Extent-3 to store extents under each
tablespace.

It also seems we will be using the Oracle tablespace syntax where
appropriate.

Comments?
-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026