This page in other versions: 9.1 / 9.2 / 9.3 / 9.4 / current (9.5)  |  Development versions: devel  |  Unsupported versions: 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 9.0



CREATE TABLESPACE -- define a new tablespace


CREATE TABLESPACE tablespacename [ OWNER username ] LOCATION 'directory'


CREATE TABLESPACE registers a new cluster-wide tablespace. The tablespace name must be distinct from the name of any existing tablespace in the database cluster.

A tablespace allows superusers to define an alternative location on the file system where the data files containing database objects (such as tables and indexes) may reside.

A user with appropriate privileges can pass tablespacename to CREATE DATABASE, CREATE TABLE, CREATE INDEX or ADD CONSTRAINT to have the data files for these objects stored within the specified tablespace.



The name of a tablespace to be created. The name cannot begin with pg_, as such names are reserved for system tablespaces.


The name of the user who will own the tablespace. If omitted, defaults to the user executing the command. Only superusers may create tablespaces, but they can assign ownership of tablespaces to non-superusers.


The directory that will be used for the tablespace. The directory must be empty and must be owned by the PostgreSQL system user. The directory must be specified by an absolute path name.


Tablespaces are only supported on systems that support symbolic links.


Create a tablespace dbspace at /data/dbs:


Create a tablespace indexspace at /data/indexes owned by user genevieve:

CREATE TABLESPACE indexspace OWNER genevieve LOCATION '/data/indexes';


CREATE TABLESPACE is a PostgreSQL extension.


July 11, 2006, 6:16 p.m.

A warning concerning tablespaces and pg_dumpall:

In order to run extensive tests on "real" data under "real" conditions, I dump the productive db-cluster with pg_dumpall and restore it with psql to a separate "test"-cluster on a different port on the same machine. (Actually I use the debian multi-cluster tools.)

This works just fine, _unless_ one makes use of tablespaces. The location of a tablespace on the harddrive is hardcoded and absolute, the second cluster would try to access the same directory.

I have not tried it, but multiple postmaster-instances cannot share a tablespace-directory, so you would get an error at best, or two corrupt clusters at worst.

My solution ist to hack the dump with a sed-script and change the directories of tablespaces (to different designated directories) before I restore to the second cluster.

This trap could be alleviated, if it was possible for tablespaces to have _relative_ paths.

Privacy Policy | About PostgreSQL
Copyright © 1996-2016 The PostgreSQL Global Development Group