MIME-Version: 1.0
References: <20230329.132155.629765142788133576.horikyota.ntt@gmail.com>
 <20230329.173456.1185961934810139447.horikyota.ntt@gmail.com>
 <CAAKRu_Yg4-kWH_EN7wtpm3z9B+H27UTmOxzzYv1Vg=YdZ6v_rw@mail.gmail.com>
 <CAD21AoCGdxYAJHmE_nXw_MFw1+Qtn3vcThRu5FiadukgQnpWeQ@mail.gmail.com>
 <935191FB-083B-4060-89FC-466F61FAA391@yesql.se> <CAAKRu_aoa0YT36q2n3xa9MZYdepeH4Jyf2EVJj=7YdC_1c974Q@mail.gmail.com>
 <CAAKRu_bSsChKsyEy1ZV2XJQ22FoDdA56efjNr9==m2TO94557w@mail.gmail.com>
 <CAD21AoDi4i4tj1Cf9BG0q2iyVhHisQ2xxVBZajEqExX6t6_b3g@mail.gmail.com>
 <CAAKRu_bkg+0WAGTxsy0HP75RzFbPwqz3ctYq1kThjFhSL69upw@mail.gmail.com>
 <1252075.1680547394@sss.pgh.pa.us> <20230403190837.qubpnwugfe2k2g46@awork3.anarazel.de>
 <CAAKRu_ap7nhmqtKQ1TRo3LzHG3FK=YpGO=O0019M3BbN7ysm3A@mail.gmail.com>
 <7E06F879-7E20-4A6A-862F-CA72CDC9A323@yesql.se> <CAAKRu_b1HjGCTsFpUnmwLNS8NeXJ+JnrDLhT1osP+Gq9HCU+Rw@mail.gmail.com>
 <CBF0083E-5893-4B35-9498-142A835D03DC@yesql.se> <CAAKRu_bJ2DJxYoMkyMo9UpoX74LY5d2Jir86QWFUftrGKWP5Bw@mail.gmail.com>
 <CA+TgmoYDYHht9zsHye3tywx7oWGMP4s_6AGefHkDsMuGHLzT7w@mail.gmail.com>
In-Reply-To: <CA+TgmoYDYHht9zsHye3tywx7oWGMP4s_6AGefHkDsMuGHLzT7w@mail.gmail.com>
From: Peter Geoghegan <pg@bowt.ie>
Date: Wed, 5 Apr 2023 13:19:39 -0700
Message-ID: <CAH2-WznhA5T3Dh=ic6Ev0jRWX7=oqJvBduqA9-Aa-TabW2vT6g@mail.gmail.com>
Subject: Re: Should vacuum process config file reload more often
To: Robert Haas <robertmhaas@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, 
	Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Masahiko Sawada <sawada.mshk@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAH2-WznhA5T3Dh%3Dic6Ev0jRWX7%3DoqJvBduqA9-Aa-TabW2vT6g%40mail.gmail.com>
Precedence: bulk

On Wed, Apr 5, 2023 at 11:56=E2=80=AFAM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> To be honest, I think that the whole system where we divide the cost
> limit across the workers is the wrong idea. Does anyone actually like
> that behavior? This patch probably shouldn't touch that, just in the
> interest of getting something done that is an improvement over where
> we are now, but I think this behavior is really counterintuitive.
> People expect that they can increase autovacuum_max_workers to get
> more vacuuming done, and actually in most cases that does not work.

I disagree. Increasing autovacuum_max_workers as a method of
increasing the overall aggressiveness of autovacuum seems like the
wrong idea. I'm sure that users do that at times, but they really
ought to have a better way of getting the same result.

ISTM that autovacuum_max_workers confuses the question of what the
maximum possible number of workers should ever be (in extreme cases)
with the question of how many workers might be a good idea given
present conditions.

> And if that behavior didn't exist, this patch would also be a whole
> lot simpler.

Probably, but the fact remains that the system level view of things is
mostly what matters. The competition between the amount of vacuuming
that we can afford to do right now and the amount of vacuuming that
we'd ideally be able to do really matters. In fact, I'd argue that the
amount of vacuuming that we'd ideally be able to do isn't a
particularly meaningful concept on its own. It's just too hard to
model what we need to do accurately -- emphasizing what we can afford
to do seems much more promising.

> Again, I don't think this is something we should try to
> address right now under time pressure, but in the future, I think we
> should consider ripping this behavior out.

-1. The delay stuff might not work as well as it should, but it at
least seems like roughly the right idea. The bigger problem seems to
be everything else -- the way that tuning autovacuum_max_workers kinda
makes sense (it shouldn't be an interesting tunable), and the problems
with the autovacuum.c scheduling being so primitive.

--=20
Peter Geoghegan