Re: autovacuum: automatically propagate updated parameters

From: Manu <manuelreyesbravo(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: autovacuum: automatically propagate updated parameters
Date: 2026-09-25 19:12:20
Message-ID: 179036354055.1964197.12261940030767792554@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> Given where we are in the cycle I am also in favor of a simpler solution unless
> it's shown to have (severe) performance regressions.

My earlier numbers counted the SetLatch() calls, not their cost, so I
measured the server's CPU with and without v3 (REL_19_STABLE
e60ee52841d, -O2, no cassert). The load is the same as before: small
tables moving in and out of the balance plus one parallel table, with
autovacuum saturated, 120 s per run, runs alternated.

3 workers, 8 runs each: median 25.75 s CPU both with and without v3.
One v3 run used 28.4 s, and it did not repeat in 7 more.

10 workers, 4 runs each: 125.8 s without v3 (sd 0.8), 126.1 s with
it (sd 0.3).

So I see no CPU cost from v3 at either size. One difference did show
up at 10 workers: v3 vacuumed 2.5% fewer tables in the same window, in
all four pairs. I have not checked why. It would fit the parallel
workers now following the rebalanced limit, but that is a guess.

The scripts and all runs are attached.

Regards,
Manu

Attachment Content-Type Size
nocfbot-av-v3-cpu.txt text/plain 7.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Corey Huinker 2026-09-25 19:35:18 Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Previous Message Manu 2026-09-25 15:38:08 Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0