Skip to content

Commit bb08e78

Browse files
committed
Doc: Fix misleading statement about VACUUM memory limits
In ec34040 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 ec34040 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 ec34040
1 parent ff18b8d commit bb08e78

File tree

1 file changed

+10
-4
lines changed

1 file changed

+10
-4
lines changed

doc/src/sgml/config.sgml

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1770,10 +1770,9 @@ include_dir 'conf.d'
17701770
setting <xref linkend="guc-autovacuum-work-mem"/>.
17711771
</para>
17721772
<para>
1773-
Additionally, <command>VACUUM</command> is only able to utilize up to
1774-
a maximum of <literal>1GB</literal> of memory, so
1775-
<varname>maintenance_work_mem</varname> values higher than this have
1776-
no effect on <command>VACUUM</command>.
1773+
Note that for the collection of dead tuple identifiers,
1774+
<command>VACUUM</command> is only able to utilize up to a maximum of
1775+
<literal>1GB</literal> of memory.
17771776
</para>
17781777
</listitem>
17791778
</varlistentry>
@@ -1797,6 +1796,13 @@ include_dir 'conf.d'
17971796
<filename>postgresql.conf</filename> file or on the server command
17981797
line.
17991798
</para>
1799+
<para>
1800+
For the collection of dead tuple identifiers, autovacuum is only able
1801+
to utilize up to a maximum of <literal>1GB</literal> of memory, so
1802+
setting <varname>autovacuum_work_mem</varname> to a value higher than
1803+
that has no effect on the number of dead tuples that autovacuum can
1804+
collect while scanning a table.
1805+
</para>
18001806
</listitem>
18011807
</varlistentry>
18021808

0 commit comments

Comments
 (0)