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

From Masahiko Sawada
Subject Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Date
Msg-id CAD21AoCSDmnejmpOnqDWq0NpC5PqEqNnoi8kVoqxFYGSJmKkFQ@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>)
List pgsql-hackers
On Wed, Jul 7, 2021 at 8:44 PM 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.

I think you meant that autovacuums can use more than 1GB of memory
during cleaning up a gin pending list (in ginInsertCleanup()). The
description updated by that commit is not true as of now as you
pointed out but IIUC it uses maintenance_work_mem *in addition to* the
same amount memory used by lazy vacuum. This memory usage seems rather
weird to me. Is it worh considering having gin pending list cleanup
use work_mem instead of maintenance_work_mem also in autovacuum cases
like btree indexes do? If we do that, the description will become
true, although we might need to update work_mem section somewhat.

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Toast compression method options
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: corruption of WAL page header is never reported