Re: Missing mention of autovacuum_work_mem
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t77078psql -h localhost -U postgresBuilt from patchset v7 (message #7), July 27, 2026 at 04:10 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t77078_7 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t77078_7 && git checkout t77078_7Patchset v7 (message #7) is on t77078_7
Hi,
There was no follow up to my message below so I'm raising it again.
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."
should be something like
(I've changed this slightly and removed maximum as it seems redundant)
"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."
Attachments:
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
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."
Thank you Laurenz,
Yes that reads better still.
Regards,
Nikolai
On Mon, Sep 20, 2021, at 10:40 AM, nikolai.berkoff wrote:
Yes that reads better still.
I'm attaching a patch with Laurenz's words.
--
Euler Taveira
EDB https://www.enterprisedb.com/
Attachments:
v1-0001-Improve-vacumming-indexes-description.patchtext/x-patch; name=v1-0001-Improve-vacumming-indexes-description.patchDownload+3-3
On Wed, 2021-09-22 at 17:45 -0300, Euler Taveira wrote:
On Mon, Sep 20, 2021, at 10:40 AM, nikolai.berkoff wrote:
Yes that reads better still.
I'm attaching a patch with Laurenz's words.
Thanks, and +1 from me.
Yours,
Laurenz Albe
On Thu, Sep 23, 2021 at 10:48:37AM +0200, Laurenz Albe wrote:
Thanks, and +1 from me.
maintenance_work_mem would be used in the context of autovacuum if
autovacuum_work_mem is -1, but it seems to me that the suggested
wording sounds like only autovacuum_work_mem is used and that it would
never fall back to maintenance_work_mem, no? I would suggest the
addition of "if specified" in the new part within parenthesis
--
Michael
On Thu, Sep 23, 2021, at 7:18 AM, Michael Paquier wrote:
On Thu, Sep 23, 2021 at 10:48:37AM +0200, Laurenz Albe wrote:
Thanks, and +1 from me.
maintenance_work_mem would be used in the context of autovacuum if
autovacuum_work_mem is -1, but it seems to me that the suggested
wording sounds like only autovacuum_work_mem is used and that it would
never fall back to maintenance_work_mem, no? I would suggest the
addition of "if specified" in the new part within parenthesis
Good point. However, I prefer "if set".
--
Euler Taveira
EDB https://www.enterprisedb.com/
On Fri, Sep 24, 2021 at 12:21:40PM -0300, Euler Taveira wrote:
Good point. However, I prefer "if set".
WFM.
--
Michael
On Sat, Sep 25, 2021 at 07:51:15AM +0900, Michael Paquier wrote:
WFM.
This has been applied and backpatched as of 1ba8410.
--
Michael