11<!--
2- $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.34 2004/09/30 02:40:23 neilc Exp $
2+ $PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.35 2004/10/29 02:11:18 neilc Exp $
33-->
44
55<chapter id="managing-databases">
@@ -347,21 +347,22 @@ dropdb <replaceable class="parameter">dbname</replaceable>
347347 </para>
348348
349349 <para>
350- By using tablespaces,a database administrator can control the disk
351- layout of a <productname>PostgreSQL</> installation. This is useful in
352- at least two ways.Firstly , if the partition or volume on which the cluster
353- was initialized runs out of space and cannot be extended logically
354- or otherwise, a tablespace can be created on a different partition
355- and used until the system can be reconfigured.
350+ By using tablespaces,an administrator can control the disk layout
351+ of a <productname>PostgreSQL</> installation. This is useful in at
352+ least two ways.First , if the partition or volume on which the
353+ cluster was initialized runs out of space and cannot be extended,
354+ a tablespace can be created on a different partition and used
355+ until the system can be reconfigured.
356356 </para>
357357
358358 <para>
359- Secondly, tablespaces allow a database administrator to arrange data
360- locations based on the usage patterns of database objects. For
361- example, an index which is very heavily used can be placed on very fast,
362- highly available disk, such as an expensive solid state device. At the same
363- time a table storing archived data which is rarely used or not performance
364- critical could be stored on a less expensive, slower disk system.
359+ Second, tablespaces allow an administrator to use knowledge of the
360+ usage pattern of database objects to optimize performance. For
361+ example, an index which is very heavily used can be placed on a
362+ very fast, highly available disk, such as an expensive solid state
363+ device. At the same time a table storing archived data which is
364+ rarely used or not performance critical could be stored on a less
365+ expensive, slower disk system.
365366 </para>
366367
367368 <para>
@@ -377,14 +378,14 @@ CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
377378 </para>
378379
379380 <note>
380- <para>
381- There is usually not much point in making more than one
382- tablespace per logical filesystem, since youcan't control the location
383- of individual files within a logical filesystem. However,
384- <productname>PostgreSQL</> does not enforce any such limitation, and
385- indeed it's not directly aware of the filesystem boundaries on your
386- system. It just stores files in the directories you tell it to use.
387- </para>
381+ 382+
383+ cannot control the location
384+
385+ <productname>PostgreSQL</> does not enforce any such limitation, and
386+ is not directly aware of the filesystem boundaries on your
387+
388+
388389 </note>
389390
390391 <para>
@@ -416,17 +417,17 @@ CREATE TABLE foo(i int) TABLESPACE space1;
416417 </para>
417418
418419 <para>
419- A schema does not in itself occupy any storage (other than a system
420- catalog entry), so assigning atablespace to aschema does not in itself
421- do anything. What this actually does is to set a default tablespace
422- for tables later created within the schema. If
420+ A schema does not in itself occupy any storage (other than a
421+ system catalog entry), so assigning aschema to atablespace does
422+ not in itself do anything. What this actually does is to set a
423+ default tablespace for tables later created within the schema. If
423424 no tablespace is mentioned when creating a schema, it inherits its
424425 default tablespace from the current database.
425426 </para>
426427
427428 <para>
428- The defaultchoice of tablespace for an index is thesame tablespace
429- already assigned to the table the index isfor .
429+ The default tablespace for an index is the tablespace associated
430+ with the table the index ison .
430431 </para>
431432
432433 <para>
