From ade8f5c8d42bef73a217999a6432db382c712b2b Mon Sep 17 00:00:00 2001 From: Neil Conway Date: Fri, 29 Oct 2004 02:11:18 +0000 Subject: [PATCH] Minor improvements to the tablespace documentation. --- doc/src/sgml/manage-ag.sgml | 55 +++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml index f1f64634fb..5db8e939e4 100644 --- a/doc/src/sgml/manage-ag.sgml +++ b/doc/src/sgml/manage-ag.sgml @@ -1,5 +1,5 @@ @@ -347,21 +347,22 @@ dropdb dbname - By using tablespaces, a database administrator can control the disk - layout of a PostgreSQL installation. This is useful in - at least two ways. Firstly, if the partition or volume on which the cluster - was initialized runs out of space and cannot be extended logically - or otherwise, a tablespace can be created on a different partition - and used until the system can be reconfigured. + By using tablespaces, an administrator can control the disk layout + of a PostgreSQL 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. - Secondly, tablespaces allow a database administrator to arrange data - locations based on the usage patterns of database objects. For - example, an index which is very heavily used can be placed on 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. + 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. @@ -377,14 +378,14 @@ CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data'; - - 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, - 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. - + + There is usually not much point in making more than one + tablespace per logical filesystem, since you cannot control the location + of individual files within a logical filesystem. However, + PostgreSQL does not enforce any such limitation, and + indeed it is not directly aware of the filesystem boundaries on your + system. It just stores files in the directories you tell it to use. + @@ -416,17 +417,17 @@ CREATE TABLE foo(i int) TABLESPACE space1; - 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 - do anything. What this actually does is to set a default tablespace - for tables later created within the schema. If + A schema does not in itself occupy any storage (other than a + system catalog entry), so assigning a schema to a tablespace does + not in itself do anything. What this actually does is to set a + default tablespace for tables later created within the schema. If no tablespace is mentioned when creating a schema, it inherits its default tablespace from the current database. - The default choice of tablespace for an index is the same tablespace - already assigned to the table the index is for. + The default tablespace for an index is the tablespace associated + with the table the index is on.