Attached patch takes a swing at improving the autovacuum wording in

maintenance.sgml.

Robert Treat

[ Also fix create domain markup.]

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 4f7c4d78243e644e8648fc6e3ad88388e6bf2c23..d347e273327be3eb09c3164e8268d64e4bbb6e3f 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -180,7 +180,8 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.47 2005/09/16 03:12:32 alvh
     rate of data modification VACUUM busy tables as
     often as once every few minutes.)  If you have multiple databases
     in a cluster, don't forget to VACUUM each one;
-    the program vacuumdb may be helpful.
+    the program 
+    may be helpful.
    
 
    
@@ -466,7 +467,7 @@ HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
    
     Beginning in PostgreSQL  8.1, there is a
     separate optional server process called the autovacuum
-    daemon, whose purpose is to automate the issuance of
+    daemon, whose purpose is to automate the execution of
     VACUUM and ANALYZE  commands.
     When enabled, the autovacuum daemon runs periodically and checks for
     tables that have had a large number of inserted, updated or deleted
@@ -521,29 +522,29 @@ vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuple
 
    
     Note that if any of the values in pg_autovacuum
-    is set to a negative number, or if a tuple is not present at all in
+    are set to a negative number, or if a tuple is not present at all in
     pg_autovacuum for any particular table, the
     equivalent value from postgresql.conf is used.
    
 
    
     Besides the base threshold values and scale factors, there are three
-    parameters that can be set for each table in pg_autovacuum: 
-    the vacuum cost delay
+    parameters that can be set for each table in pg_autovacuum. 
+    The first parameter, pg_autovacuum.enabled,
+    can be used to instruct the autovacuum daemon to skip any particular table
+    by setting it to false.
+    The other two, the vacuum cost delay
     (pg_autovacuum.vac_cost_delay)
     and the vacuum cost limit
-    (pg_autovacuum.vac_cost_limit).
-    They are used to set table-specific values for the
+    (pg_autovacuum.vac_cost_limit), 
+    are used to set table-specific values for the
     
     feature.  The above note about negative values also applies here, but
     also note that if the postgresql.conf variables
     autovacuum_vacuum_cost_limit and
     autovacuum_vacuum_cost_delay are also set to negative 
-    values, the vacuum_cost_limit and
+    values, the global vacuum_cost_limit and
     vacuum_cost_delay values will be used instead.
-    The other parameter, pg_autovacuum.enabled,
-    can be used to instruct the autovacuum daemon to skip any particular table
-    by setting it to false.
    
 
    

diff --git a/doc/src/sgml/ref/create_domain.sgml b/doc/src/sgml/ref/create_domain.sgml
index bddfb572875c806c6f9108f7bfe714910d600af5..0f52ff67f77cc7d58f2170ceb32715feef5a4021 100644 (file)
--- a/doc/src/sgml/ref/create_domain.sgml
+++ b/doc/src/sgml/ref/create_domain.sgml
@@ -1,5 +1,5 @@
 
 
@@ -52,10 +52,16 @@ where constraint is:
    into a single location for maintenance.  For example, an email address
    column may be used in several tables, all with the same properties.
    Define a domain and use that rather than setting up each table's
-   constraints individually. Keep in mind also that declaring a
-   function result value as a domain is pretty dangerous, because none of
-   the PLs enforce domain constraints on their results.
+   constraints individually. 
   
+
+  
+  
+   Keep in mind also that declaring a function result value as a domain 
+   is pretty dangerous, because none of the PLs enforce domain constraints 
+   on their results.
+  
+