Reword paragraph about the autovacuum_max_workers setting. Patch from

Jim Nasby.

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index bbe73198262f4f2f3fa9e4f91b5b9961dcda195d..40e9527d0cf23be0b382b78239220cae68b87c97 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Routine Database Maintenance Tasks
@@ -496,16 +496,16 @@ HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
    
 
    
-    There is a limit of  worker
-    processes that may be running at any time, so if the VACUUM
-    and ANALYZE work to do takes too long to run, the deadline may
-    be failed to meet for other databases.  Also, if a particular database
-    takes a long time to process, more than one worker may be processing it
-    simultaneously.  The workers are smart enough to avoid repeating work that
-    other workers have done, so this is normally not a problem.  Note that the
-    number of running workers does not count towards the 
-    linkend="guc-max-connections"> nor the 
-    linkend="guc-superuser-reserved-connections"> limits.
+    The  setting limits how many
+    workers may be running at any time. If several large tables all become
+    eligible for vacuuming in a short amount of time, all autovacuum workers
+    may end up vacuuming those tables for a very long time. This would result
+    in other tables and databases not being vacuumed until a worker became
+    available. There is also not a limit on how many workers might be in a
+    single database, but workers do try and avoid repeating work that has
+    already been done by other workers. Note that the number of running
+    workers does not count towards the  nor
+    the linkend="guc-superuser-reserved-connections"> limits.