Home Explore Blog CI



postgresql

7th chunk of `doc/src/sgml/manage-ag.sgml`
2dbe83edb06a8ce8fe7fdebc73680e2e741f525d59eab4c20000000100000b64
 cluster and
     <emphasis>cannot</emphasis> be treated as an autonomous collection
     of data files. They are dependent on metadata contained in the main
     data directory, and therefore cannot be attached to a different
     database cluster or backed up individually.  Similarly, if you lose
     a tablespace (file deletion, disk failure, etc.), the database cluster
     might become unreadable or unable to start.  Placing a tablespace
     on a temporary file system like a RAM disk risks the reliability of
     the entire cluster.
   </para>
  </warning>

  <para>
   To define a tablespace, use the <xref
   linkend="sql-createtablespace"/>
   command, for example:<indexterm><primary>CREATE TABLESPACE</primary></indexterm>:
<programlisting>
CREATE TABLESPACE fastspace LOCATION '/ssd1/postgresql/data';
</programlisting>
   The location must be an existing, empty directory that is owned by
   the <productname>PostgreSQL</productname> operating system user.  All objects subsequently
   created within the tablespace will be stored in files underneath this
   directory.  The location must not be on removable or transient storage,
   as the cluster might fail to function if the tablespace is missing
   or lost.
  </para>

  <note>
   <para>
    There is usually not much point in making more than one
    tablespace per logical file system, since you cannot control the location
    of individual files within a logical file system.  However,
    <productname>PostgreSQL</productname> does not enforce any such limitation, and
    indeed it is not directly aware of the file system boundaries on your
    system.  It just stores files in the directories you tell it to use.
   </para>
  </note>

  <para>
   Creation of the tablespace itself must be done as a database superuser,
   but after that you can allow ordinary database users to use it.
   To do that, grant them the <literal>CREATE</literal> privilege on it.
  </para>

  <para>
   Tables, indexes, and entire databases can be assigned to
   particular tablespaces. To do so, a user with the <literal>CREATE</literal>
   privilege on a given tablespace must pass the tablespace name as a
   parameter to the relevant command. For example, the following creates
   a table in the tablespace <literal>space1</literal>:
<programlisting>
CREATE TABLE foo(i int) TABLESPACE space1;
</programlisting>
  </para>

  <para>
   Alternatively, use the <xref linkend="guc-default-tablespace"/> parameter:
<programlisting>
SET default_tablespace = space1;
CREATE TABLE foo(i int);
</programlisting>
   When <varname>default_tablespace</varname> is set to anything but an empty
   string, it supplies an implicit <literal>TABLESPACE</literal> clause for
   <command>CREATE TABLE</command> and <command>CREATE INDEX</command> commands that
   do not have an explicit one.
  </para>

  <para>
   There is also a <xref linkend="guc-temp-tablespaces"/>

Title: Creating and Managing Tablespaces in PostgreSQL
Summary
Tablespaces are created with CREATE TABLESPACE, pointing to an existing, empty directory owned by the PostgreSQL user. This location should be permanent, not removable storage. Multiple tablespaces per logical file system are generally unnecessary. Superusers create tablespaces, then grant CREATE privilege to other users. Tables, indexes, and databases can be assigned to tablespaces using the TABLESPACE parameter during creation, or by setting the default_tablespace parameter for implicit assignment to CREATE TABLE and CREATE INDEX commands. The location must not be on removable or transient storage, as the cluster might fail to function if the tablespace is missing or lost.