Improve tablespace discussion, and bring it up to date with code.

This commit is contained in:
Tom Lane 2004-08-07 19:02:43 +00:00
parent ff2c8950fe
commit c2f14a7cdf

View File

@ -1,5 +1,5 @@
<!-- <!--
$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.31 2004/06/21 04:06:03 tgl Exp $ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.32 2004/08/07 19:02:43 tgl Exp $
--> -->
<chapter id="managing-databases"> <chapter id="managing-databases">
@ -32,8 +32,8 @@ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.31 2004/06/21 04:06:03 tgl Ex
are accessible from each database within the cluster.) More are accessible from each database within the cluster.) More
accurately, a database is a collection of schemas and the schemas accurately, a database is a collection of schemas and the schemas
contain the tables, functions, etc. So the full hierarchy is: contain the tables, functions, etc. So the full hierarchy is:
server, database, schema, table (or something else instead of a server, database, schema, table (or some other kind of object,
table). such as a function).
</para> </para>
<para> <para>
@ -58,8 +58,8 @@ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.31 2004/06/21 04:06:03 tgl Ex
<note> <note>
<para> <para>
<acronym>SQL</> calls databases <quote>catalogs</>, but there is no The <acronym>SQL</> standard calls databases <quote>catalogs</>, but there
difference in practice. is no difference in practice.
</para> </para>
</note> </note>
</sect1> </sect1>
@ -68,14 +68,16 @@ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.31 2004/06/21 04:06:03 tgl Ex
<title>Creating a Database</title> <title>Creating a Database</title>
<para> <para>
In order to create a databases, the <productname>PostgreSQL</> In order to create a database, the <productname>PostgreSQL</>
server must be up and running (see <xref server must be up and running (see <xref
linkend="postmaster-start">). linkend="postmaster-start">).
</para> </para>
<para> <para>
Databases are created with the SQL command <command>CREATE Databases are created with the SQL command
DATABASE</command>:<indexterm><primary>CREATE DATABASE</></> <xref linkend="sql-createdatabase"
endterm="sql-createdatabase-title">:<indexterm><primary>CREATE
DATABASE</></>
<synopsis> <synopsis>
CREATE DATABASE <replaceable>name</>; CREATE DATABASE <replaceable>name</>;
</synopsis> </synopsis>
@ -105,7 +107,7 @@ CREATE DATABASE <replaceable>name</>;
</para> </para>
<para> <para>
The name <literal>template1</literal> is no accident: When a new The name <literal>template1</literal> is no accident: when a new
database is created, the template database is essentially cloned. database is created, the template database is essentially cloned.
This means that any changes you make in <literal>template1</> are This means that any changes you make in <literal>template1</> are
propagated to all subsequently created databases. This implies that propagated to all subsequently created databases. This implies that
@ -280,8 +282,8 @@ createdb -T template0 <replaceable>dbname</>
<acronym>GEQO</acronym> optimizer for a given database, you'd <acronym>GEQO</acronym> optimizer for a given database, you'd
ordinarily have to either disable it for all databases or make sure ordinarily have to either disable it for all databases or make sure
that every connecting client is careful to issue <literal>SET geqo that every connecting client is careful to issue <literal>SET geqo
TO off;</literal>. To make this setting the default you can TO off;</literal>. To make this setting the default within a particular
execute the command database, you can execute the command
<programlisting> <programlisting>
ALTER DATABASE mydb SET geqo TO off; ALTER DATABASE mydb SET geqo TO off;
</programlisting> </programlisting>
@ -299,12 +301,13 @@ ALTER DATABASE mydb SET geqo TO off;
<title>Destroying a Database</title> <title>Destroying a Database</title>
<para> <para>
Databases are destroyed with the command <command>DROP Databases are destroyed with the command
DATABASE</command>:<indexterm><primary>DROP DATABASE</></> <xref linkend="sql-dropdatabase"
endterm="sql-dropdatabase-title">:<indexterm><primary>DROP DATABASE</></>
<synopsis> <synopsis>
DROP DATABASE <replaceable>name</>; DROP DATABASE <replaceable>name</>;
</synopsis> </synopsis>
Only the owner of the database (i.e., the user that created it) or Only the owner of the database (i.e., the user that created it), or
a superuser, can drop a database. Dropping a database removes all objects a superuser, can drop a database. Dropping a database removes all objects
that were that were
contained within the database. The destruction of a database cannot contained within the database. The destruction of a database cannot
@ -335,7 +338,7 @@ dropdb <replaceable class="parameter">dbname</replaceable>
<title>Tablespaces</title> <title>Tablespaces</title>
<para> <para>
Tablespaces in <productname>PostgreSQL</> allow database superusers to Tablespaces in <productname>PostgreSQL</> allow database administrators to
define locations in the file system where the files representing define locations in the file system where the files representing
database objects can be stored. Once created, a tablespace can be referred database objects can be stored. Once created, a tablespace can be referred
to by name when creating database objects. to by name when creating database objects.
@ -360,7 +363,37 @@ dropdb <replaceable class="parameter">dbname</replaceable>
</para> </para>
<para> <para>
Databases, schemas, tables, indexes and sequences can all be placed in To define a tablespace, use the <xref linkend="sql-createtablespace"
endterm="sql-createtablespace-title"> command, for
example:<indexterm><primary>CREATE TABLESPACE</></>
<programlisting>
CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
</programlisting>
The location must be an existing, empty directory that is owned by
the <productname>PostgreSQL</> system user. All objects subsequently
created within the tablespace will be stored in files underneath this
directory.
</para>
<note>
<para>
There is usually not much point in making more than one
tablespace per logical filesystem, since you can't control the location
of individual files within a logical filesystem. However,
<productname>PostgreSQL</> does not enforce any such limitation, and
indeed it's not directly aware of the filesystem 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 make use of it.
To do that, grant them the <literal>CREATE</> privilege on it.
</para>
<para>
Databases, schemas, tables, and indexes can all be assigned to
particular tablespaces. To do so, a user with the <literal>CREATE</> particular tablespaces. To do so, a user with the <literal>CREATE</>
privilege on a given tablespace must pass the tablespace name as a privilege on a given tablespace must pass the tablespace name as a
parameter to the relevant command. For example, the following creates parameter to the relevant command. For example, the following creates
@ -385,7 +418,7 @@ CREATE TABLE foo(i int) TABLESPACE space1;
A schema does not in itself occupy any storage (other than a system A schema does not in itself occupy any storage (other than a system
catalog entry), so assigning a tablespace to a schema does not in itself catalog entry), so assigning a tablespace to a schema does not in itself
do anything. What this actually does is to set a default tablespace do anything. What this actually does is to set a default tablespace
for tables, indexes, and sequences later created within the schema. If for tables later created within the schema. If
no tablespace is mentioned when creating a schema, it inherits its no tablespace is mentioned when creating a schema, it inherits its
default tablespace from the current database. default tablespace from the current database.
</para> </para>
@ -396,10 +429,10 @@ CREATE TABLE foo(i int) TABLESPACE space1;
</para> </para>
<para> <para>
Another way to state the above rules is that when a schema, table, index Another way to state the above rules is that when a schema, table, or index
or sequence is created without specifying a tablespace, the object is created without specifying a tablespace, the object
inherits its logical parent's tablespace. A schema will be created in the inherits its logical parent's tablespace. A schema will be created in the
current database's tablespace; a table or sequence will be created in the current database's tablespace; a table will be created in the
tablespace of the schema it is being created in; an index will be created tablespace of the schema it is being created in; an index will be created
in the tablespace of the table underlying the index. in the tablespace of the table underlying the index.
</para> </para>