doc: Adjust note about pg_upgrade's --jobs option.

nathan-bossart · nathan-bossart · commit 3c472a18296e · 2025-03-08T14:28:16.000-06:00
Presently, this section lists a couple of parallelized parts of pg_upgrade and suggests a starting point for setting the --jobs option. The list of parallelized tasks is not particularly actionable, and the phrasing for the --jobs recommendation is confusing to some readers. This commit attempts to improve this section by eliminating the list of parallelized tasks and instead highlighting that --jobs is most useful for clusters with multiple databases or tablespaces. Additionally, the recommendation for setting --jobs is simplified to suggest starting with the number of CPU cores. Reported-by: Magnus Hagander <magnus@hagander.net> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Magnus Hagander <magnus@hagander.net> Discussion: https://postgr.es/m/Z8dBn_5iGLNuYiPo%40nathan
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
@@ -533,12 +533,11 @@ NET STOP postgresql-&majorversion;
     </para>
 
     <para>
-     The <option>--jobs</option> option allows multiple CPU cores to be used
-     for copying/linking of files, dumping and restoring database schemas
-     in parallel, etc.;  a good place to start is the maximum of the number of
-     CPU cores and tablespaces.  This option can dramatically reduce the
-     time to upgrade a multi-database server running on a multiprocessor
-     machine.
+     Setting <option>--jobs</option> to 2 or higher allows pg_upgrade to
+     process multiple databases and tablespaces in parallel.  A good starting
+     point is the number of CPU cores on the machine.  This option can
+     substantially reduce the upgrade time for multi-database and
+     multi-tablespace servers.
     </para>
 
     <para>
