[hackers-jp: 157] Fw: [HACKERS] Table Spaces
井久保 寛明
ikuboh @ nttdata.co.jp
2004年 5月 20日 (木) 13:10:01 JST
井久保です。
Table Space も、パッチが出ていますね。
下のほうに書いてあるように、CREATE TABLESPACE ... で、ファイル
システム上のディレクトリを指定したテーブルスペースを作り、
あとは、table や index などを作成するときに、どのテーブルスペース
に割り当てるかを指定するところくらいまでは、動くみたいですね。
Forwarded by 井久保 寛明 <ikuboh@nttdata.co.jp>
----------------------- Original Message -----------------------
From: Gavin Sherry <swm @ linuxworld.com.au>
To: pgsql-hackers @ postgresql.org
Date: Mon, 17 May 2004 20:28:32 +1000 (EST)
Subject: [HACKERS] Table Spaces
----
Hi all,
Attached is a patch against HEAD implementing tablespaces.
I've done some testing on Linux and BSD. I've also compiled without
HAVE_SYMLINK defined -- which determines whether or not tablespaces are
available.
The reason for this is that symlinks are used extensively to simplify
access to relations in hairy places.
This is extensive discussion of this in the archives.
There are some outstanding TODOs. These include
pg_dump
documentation
regression tests
comment on
Chris KL has offered to tackle these.
Other outstanding things which need to be resolved:
XLog entries:
Within a tablespace, the files for different databases are isolated into
directories. Those directory names are the database oid for those files.
Since we create those files, we should log them. The question is, what is
the best way: appending it to an xlrec and storing its length in the xlrec
or adding another rdata with that in it?
The same goes for symlinks, where we need to store the oldpath and
newpath.
Alternative database location:
Should this code be removed now?
Drop tablespace:
I haven't added an interlock here (as suggested by Tom) to handle
situations where one transaction schedules the removal of a tablespace and
concurrently another transaction makes use of that tablespace. I'd
appreciate some advice on what this would look like: should a command
creating an object touch a CREATE a file and a DROP TABLESPACE block until
the file goes away, then check if it can drop the tablespace (ie, that the
tablespace is empty)? Likewise when DROP TABLESPACE proceeds, should it
block creates?
The other thing is handling DROP TABLESPACE in a transaction where the
tablespace has been emptied (using DROP TABLE, etc) during that
transaction. Because we only schedule the unlink() of the relation, the
data files will (and must) still be around. Is it reasonable to look
inside PendingRelDeletes to see if the tablespace will be empty at COMMIT?
Basic usage rundown
initdb sets up a new directory pg_tablespaces with some symlinks with in
it. To create a tablespace, you must first up create a tablespace
directory. Then you can create a tablespace inside postgres using:
CREATE TABLESPACE <name> LOCATION '/path/to/tbl/dir'
Then, the DDL commands can have a tablespace associatged with it:
CREATE DATABASE ... TABLESPACE <name>
CREATE SCHEMA ... TABLESPACE <name>
CREATE TABLE ... TABLESPACE <name>
CREATE INDEX ... TABLESPACE <name>
CREATE SEQUENCE ... TABLESPACE <name>
Comments, criticisms, etc, all welcome, of course.
Thanks,
Gavin
--------------------- Original Message Ends --------------------
---
井久保 寛明 (Hiroaki Ikubo)
NTTデータ先端技術 (株) オープンソース技術部
E-mail: ikubo@intellilink.co.jp (E-mail: ikuboh@nttdata.co.jp)
hackers-jp メーリングリストの案内