Re: maintenance_work_mem used by Vacuum - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: maintenance_work_mem used by Vacuum
Date
Msg-id CAA4eK1JhY88BXC=ZK=89MALm+LyMkMhi6WG6AZfE4+Kij6mebg@mail.gmail.com
Whole thread Raw
In response to Re: maintenance_work_mem used by Vacuum  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: maintenance_work_mem used by Vacuum
List pgsql-hackers
On Tue, Oct 8, 2019 at 1:48 AM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Mon, Oct 7, 2019 at 12:28 PM Robert Haas <robertmhaas@gmail.com> wrote:
> > I would say that sucks, because it makes it harder to set
> > maintenance_work_mem correctly.  Not sure how hard it would be to fix,
> > though.
>
> ginInsertCleanup() may now be the worst piece of code in the entire
> tree, so no surprised that it gets this wrong too.
>
> 2016's commit e2c79e14d99 ripped out the following comment about the
> use of maintenance_work_mem by ginInsertCleanup():
>
> @@ -821,13 +847,10 @@ ginInsertCleanup(GinState *ginstate,
>   * Is it time to flush memory to disk? Flush if we are at the end of
>   * the pending list, or if we have a full row and memory is getting
>   * full.
> - *
> - * XXX using up maintenance_work_mem here is probably unreasonably
> - * much, since vacuum might already be using that much.
>   */
>
> ISTM that the use of maintenance_work_mem wasn't given that much
> thought originally.
>

One idea to something better could be to check, if there is a GIN
index on a table, then use 1/4 (25% or whatever) of
maintenance_work_mem for GIN indexes and 3/4 (75%) of
maintenance_work_mem for collection dead tuples.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Updated some links which are not working with new links
Next
From: Amit Kapila
Date:
Subject: Re: maintenance_work_mem used by Vacuum