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 CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@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  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
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.

Right now I'm considering if it might just be better to revert
ec34040af and call it quits here.

David



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Pipeline mode and PQpipelineSync()
Next
From: Masahiko Sawada
Date:
Subject: [PoC] Improve dead tuple storage for lazy vacuum