On Wed, Apr 5, 2023 at 1:38 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> Not to derail this thread, and pre-empt a thread where this can be discussed in
> its own context, but isn't that kind of the main problem? Tuning autovacuum is
> really complicated and one of the parameters that I think universally seem to
> make sense to users is just autovacuum_max_workers. I agree that it doesn't do
> what most think it should, but a quick skim of the name and docs can probably
> lead to a lot of folks trying to use it as hammer.
I think that I agree. I think that the difficulty of tuning autovacuum
is the actual real problem. (Or maybe it's just very closely related
to the real problem -- the precise definition doesn't seem important.)
There seems to be a kind of physics envy to some of these things.
False precision. The way that the mechanisms actually work (the
autovacuum scheduling, freeze_min_age, and quite a few other things)
*are* simple. But so are the rules of Conway's game of life, yet
people seem to have a great deal of difficulty predicting how it will
behave in any given situation. Any design that focuses on the
immediate consequences of any particular policy while ignoring second
order effects isn't going to work particularly well. Users ought to be
able to constrain the behavior of autovacuum using settings that
express what they want in high level terms. And VACUUM ought to have
much more freedom around finding the best way to meet those high level
goals over time (e.g., very loose rules about how much we need to
advance relfrozenxid by during any individual VACUUM).
--
Peter Geoghegan
