From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: allow changing autovacuum_max_workers without restarting |
Date: | 2024-04-12 17:27:40 |
Message-ID: | DC833F51-881A-47F9-AEF6-B2E1DE46CDC8@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I spent sometime reviewing/testing the POC. It is relatively simple with a lot
of obvious value.
I tested with 16 tables that constantly reach the autovac threashold and the
patch did the right thing. I observed concurrent autovacuum workers matching
the setting as I was adjusting it dynamically.
As you mention above, If there are more autovacs in progress and a new lower setting
is applied, we should not take any special action on those autovacuums, and eventually
the max number of autovacuum workers will match the setting.
I also tested by allowing user connections to reach max_connections, and observed the
expected number of autovacuums spinning up and correctly adjusted.
Having autovacuum tests ( unless I missed something ) like the above is a good
general improvement, but it should not be tied to this.
A few comments on the POC patch:
1/ We should emit a log when autovacuum_workers is set higher than the max.
2/ should the name of the restart limit be "reserved_autovacuum_workers"?
Regards,
Sami Imseih
AWS (Amazon Web Services)
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Huinker | 2024-04-12 17:36:28 | Importing Extended Statistics |
Previous Message | Heikki Linnakangas | 2024-04-12 17:03:03 | PG_TEST_EXTRAs by theme rather than test name (Re: pgsql: Add tests for libpq gssencmode and sslmode options) |