Message-ID: <b48ec99bfbb9eaf329fd9c3e7a20551810244882.camel@cybertec.at>
Subject: Re: Missing mention of autovacuum_work_mem
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "nikolai.berkoff" <nikolai.berkoff@pm.me>,
	"pgsql-docs@lists.postgresql.org"
	 <pgsql-docs@lists.postgresql.org>
Date: Mon, 20 Sep 2021 15:09:36 +0200
In-Reply-To: 
 <1kIqf6Q1G-wVkQkeg_BRSpcmy77hNfh9vlLQ3AF1APT-pKHRYT3z1IuDC5K2w83-4Qa016V1SfWJfF1v0Z0qf6141DbLcpIZJY3edlBEkCs=@pm.me>
References: 
	<1kIqf6Q1G-wVkQkeg_BRSpcmy77hNfh9vlLQ3AF1APT-pKHRYT3z1IuDC5K2w83-4Qa016V1SfWJfF1v0Z0qf6141DbLcpIZJY3edlBEkCs=@pm.me>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b48ec99bfbb9eaf329fd9c3e7a20551810244882.camel%40cybertec.at>
Precedence: bulk

On Mon, 2021-09-20 at 08:07 +0000, nikolai.berkoff wrote:
> I can see in
> src/backend/access/heap/vacuumlazy.c
> that compute_max_dead_tuples uses autovacuum_work_mem when it is given.
>
> The "vacuuming indexes" documentation has:
>
> > "If a table has any indexes, this will happen at least once per vacuum,
> > after the heap has been completely scanned. It may happen multiple times per
> > vacuum if maintenance_work_mem is insufficient to store the number of dead
> > tuples found."

Your suggested change is:

> "If a table has any indexes, this will happen at least once per vacuum,
> after the heap has been completely scanned. It may happen multiple times per
> vacuum if the memory is insufficient to store the number of dead
> tuples found. The memory is set via the maintenance_work_mem unless
> it is an autovacuum then autovacuum_work_mem will be used."

Why not keep it simple with

"If a table has any indexes, this will happen at least once per vacuum,
 after the heap has been completely scanned. It may happen multiple times per
 vacuum if maintenance_work_mem (or, in the case of autovacuum,
 autovacuum_work_mem) is insufficient to store the number of dead
 tuples found."

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com