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 6b38da6879dd80148c5d73e661e6db0a5985f386..dcc2a1801d0fda196b8a63bb33f74b06a316a63c 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -496,16 +496,16 @@ HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".
    </para>
 
    <para>
-    There is a limit of <xref linkend="guc-autovacuum-max-workers"> worker
-    processes that may be running at any time, so if the <command>VACUUM</>
-    and <command>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 <xref
-    linkend="guc-max-connections"> nor the <xref
-    linkend="guc-superuser-reserved-connections"> limits.
+    The <xref linkend="guc-autovacuum-max-workers"> 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 <xref linkend="guc-max-connections"> nor
+    the <xref linkend="guc-superuser-reserved-connections"> limits.
    </para>
 
    <para>