Minor improvements to the tablespace documentation.

diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index f1f64634fb95b745b96526a320c93c38c4b5619d..5db8e939e4d86202c773c877f7579e16788f6301 100644 (file)
--- 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.