Re: allow changing autovacuum_max_workers without restarting

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-18 05:05:03
Message-ID: 37F50121-2DC5-4B7D-AB8F-FC2A0CD827A5@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Here is a first attempt at a proper patch set based on the discussion thus
> far. I've split it up into several small patches for ease of review, which
> is probably a bit excessive. If this ever makes it to commit, they could
> likely be combined.

I looked at the patch set. With the help of DEBUG2 output, I tested to ensure
that the the autovacuum_cost_limit balance adjusts correctly when the
autovacuum_max_workers value increases/decreases. I did not think the
patch will break this behavior, but it's important to verify this.

Some comments on the patch:

1. A nit. There should be a tab here.

- dlist_head av_freeWorkers;
+ dclist_head av_freeWorkers;

2. autovacuum_max_worker_slots documentation:

+ <para>
+ Note that the value of <xref linkend="guc-autovacuum-max-workers"/> is
+ silently capped to this value.
+ </para>

This comment looks redundant in the docs, since the entry
for autovacuum_max_workers that follows mentions the
same.

3. The docs for autovacuum_max_workers should mention that when
the value changes, consider adjusting the autovacuum_cost_limit/cost_delay.

This is not something new. Even in the current state, users should think about
these settings. However, it seems even important if this value is to be
dynamically adjusted.

Regards,

Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-18 05:25:16 Re: WIP Incremental JSON Parser
Previous Message Andrei Lepikhov 2024-04-18 05:01:13 Re: POC: GROUP BY optimization