public inbox for [email protected]  
help / color / mirror / Atom feed
From: David Rowley <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Martín Marqués <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Date: Mon, 9 Aug 2021 14:44:13 +1200
Message-ID: <CAApHDvqqBsjxLxvs2RdAzXjVBYDVAZ+uqYuxT9yviF05k-bUgw@mail.gmail.com> (raw)
In-Reply-To: <CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com>
References: <CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@mail.gmail.com>
	<[email protected]>
	<CAApHDvqu_6JetmiPUuM-_f=r7GHXiaxLXJu8JFe-vjMPHW73eg@mail.gmail.com>
	<CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com>

On Wed, 7 Jul 2021 at 23:44, David Rowley <[email protected]> wrote:
>
> On Sun, 4 Jul 2021 at 22:38, David Rowley <[email protected]> wrote:
> > I could do with a 2nd opinion about if we should just adjust the
> > maximum value for the autovacuum_work_mem GUC to 1GB in master.
> >
> > I'm also not sure if since we'd not backpatch the GUC max value
> > adjustment if we need to document the upper limit in the manual.
>
> I was just looking at this again and I see that GIN indexes are able
> to use more than 1GB of memory during VACUUM. That discovery makes me
> think having the docs say that vacuum cannot use more than 1GB of
> memory is at best misleading and more likely just incorrect.

The attached patch aims to put right where I went wrong with the
documentation about vacuum/autovacuum only using maintainance_work_mem
memory for dead tuple collection.

I plan to push this and backpatch to 9.6 shortly unless there are any
better ideas.

What's in there right now is wrong and I want that fixed before the
cut-off for the next set of bug fix releases.

David


Attachments:

  [application/octet-stream] fix_wrong_documentation_on_vacuum_mem_limits.patch (1.4K, 2-fix_wrong_documentation_on_vacuum_mem_limits.patch)
  download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 3eefe3811a..30bca45657 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1894,10 +1894,9 @@ include_dir 'conf.d'
         setting <xref linkend="guc-autovacuum-work-mem"/>.
        </para>
        <para>
-        Additionally, <command>VACUUM</command> is only able to utilize up to
-        a maximum of <literal>1GB</literal> of memory, so
-        <varname>maintenance_work_mem</varname> values higher than this have
-        no effect on <command>VACUUM</command>.
+        Note that for the collection of dead tuple identifiers,
+        <command>VACUUM</command> is only able to utilize up to a maximum of
+        <literal>1GB</literal> of memory.
        </para>
       </listitem>
      </varlistentry>
@@ -1921,6 +1920,14 @@ include_dir 'conf.d'
         <filename>postgresql.conf</filename> file or on the server command
         line.
        </para>
+       <para>
+        For the collection of dead tuple identifiers,
+        autovacuum is only able to utilize up to a maximum of
+        <literal>1GB</literal> of memory, so setting
+        <varname>autovacuum_work_mem</varname> to a value higher than that has
+        no effect on the number of dead tuples that autovacuum can collect
+        while scanning a table.
+       </para>
       </listitem>
      </varlistentry>
 


reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
  In-Reply-To: <CAApHDvqqBsjxLxvs2RdAzXjVBYDVAZ+uqYuxT9yviF05k-bUgw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox