Doc: Fix misleading statement about VACUUM memory limits
authorDavid Rowley
Mon, 9 Aug 2021 04:46:49 +0000 (16:46 +1200)
committerDavid Rowley
Mon, 9 Aug 2021 04:46:49 +0000 (16:46 +1200)
In ec34040af I added a mention that there was no point in setting
maintenance_work_limit to anything higher than 1GB for vacuum, but that
was incorrect as ginInsertCleanup() also looks at what
maintenance_work_mem is set to during VACUUM and that's not limited to
1GB.

Here I attempt to make it more clear that the limitation is only around
the number of dead tuple identifiers that we can collect during VACUUM.

I've also added a note to autovacuum_work_mem to mention this limitation.
I didn't do that in ec34040af as I'd had some wrong-headed ideas about
just limiting the maximum value for that GUC to 1GB.

Author: David Rowley
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com
Backpatch-through: 9.6, same as ec34040af

doc/src/sgml/config.sgml

index d5956833e4732cbbf941c69b855371b2ce164d55..8af2891191d986a31bb161879a3720b02c03957c 100644 (file)
@@ -1894,10 +1894,9 @@ include_dir 'conf.d'
         setting .
        
        
-        Additionally, VACUUM is only able to utilize up to
-        a maximum of 1GB of memory, so
-        maintenance_work_mem values higher than this have
-        no effect on VACUUM.
+        Note that for the collection of dead tuple identifiers,
+        VACUUM is only able to utilize up to a maximum of
+        1GB of memory.
        
       
      
@@ -1921,6 +1920,13 @@ include_dir 'conf.d'
         postgresql.conf file or on the server command
         line.
        
+       
+        For the collection of dead tuple identifiers, autovacuum is only able
+        to utilize up to a maximum of 1GB of memory, so
+        setting autovacuum_work_mem to a value higher than
+        that has no effect on the number of dead tuples that autovacuum can
+        collect while scanning a table.
+