Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM - Mailing list pgsql-hackers

From David Rowley
Subject Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Date
Msg-id CAApHDvqqBsjxLxvs2RdAzXjVBYDVAZ+uqYuxT9yviF05k-bUgw@mail.gmail.com
Whole thread Raw
In response to Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
List pgsql-hackers
On Wed, 7 Jul 2021 at 23:44, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sun, 4 Jul 2021 at 22:38, David Rowley <dgrowleyml@gmail.com> 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: PG Docs - CREATE SUBSCRIPTION option list order
Next
From: Amit Kapila
Date:
Subject: Re: Small documentation improvement for ALTER SUBSCRIPTION