Note that users can still alter this setting during their sessions; it
   will only be the default.  To undo any such setting, use
   <literal>ALTER DATABASE <replaceable>dbname</replaceable> RESET
   <replaceable>varname</replaceable></literal>.
  </para>
 </sect1>

 <sect1 id="manage-ag-dropdb">
  <title>Destroying a Database</title>

  <para>
   Databases are destroyed with the command
   <xref linkend="sql-dropdatabase"/>:<indexterm><primary>DROP DATABASE</primary></indexterm>
<synopsis>
DROP DATABASE <replaceable>name</replaceable>;
</synopsis>
   Only the owner of the database, or
   a superuser, can drop a database. Dropping a database removes all objects
   that were
   contained within the database. The destruction of a database cannot
   be undone.
  </para>

  <para>
   You cannot execute the <command>DROP DATABASE</command> command
   while connected to the victim database. You can, however, be
   connected to any other database, including the <literal>template1</literal>
   database.
   <literal>template1</literal> would be the only option for dropping the last user database of a
   given cluster.
  </para>

  <para>
   For convenience, there is also a shell program to drop
   databases, <xref linkend="app-dropdb"/>:<indexterm><primary>dropdb</primary></indexterm>
<synopsis>
dropdb <replaceable class="parameter">dbname</replaceable>
</synopsis>
   (Unlike <command>createdb</command>, it is not the default action to drop
   the database with the current user name.)
  </para>
 </sect1>

 <sect1 id="manage-ag-tablespaces">
  <title>Tablespaces</title>

  <indexterm zone="manage-ag-tablespaces">
   <primary>tablespace</primary>
  </indexterm>

  <para>
   Tablespaces in <productname>PostgreSQL</productname> allow database administrators to
   define locations in the file system where the files representing
   database objects can be stored. Once created, a tablespace can be referred
   to by name when creating database objects.
  </para>

  <para>
   By using tablespaces, an administrator can control the disk layout
   of a <productname>PostgreSQL</productname> installation. This is useful in at
   least two ways. First, if the partition or volume on which the
   cluster was initialized runs out of space and cannot be extended,
   a tablespace can be created on a different partition and used
   until the system can be reconfigured.
  </para>

  <para>
   Second, tablespaces allow an administrator to use knowledge of the
   usage pattern of database objects to optimize performance. For
   example, an index which is very heavily used can be placed on a
   very fast, highly available disk, such as an expensive solid state
   device. At the same time a table storing archived data which is
   rarely used or not performance critical could be stored on a less
   expensive, slower disk system.
  </para>

  <warning>
   <para>
     Even though located outside the main PostgreSQL data directory,
     tablespaces are an integral part of the database 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