MIME-Version: 1.0
References: 
 <CAApHDvoCFQxaQjUncTAtCRFAeANe2tpc-WCkJue=FaXRYOkV=Q@mail.gmail.com>
 <CAA5RZ0sw+9rEaW9taNpRZWvuLYMjRa9iibneGfB2ftNSUHT0Ww@mail.gmail.com>
 <CAApHDvq_j+GVqX_ZAmvn236Mgg5OYQ6_s9kVsyoo1tJa2RJ=2w@mail.gmail.com>
 <CAA5RZ0udjEYJupob5tv3286e28bMpajgsy+4nAbxg73YyigZFw@mail.gmail.com>
 <CAApHDvq9ecYSetXUhjMc7E_Jcc7gxxRkA0LosX9PP1-jM_Ak8A@mail.gmail.com>
 <aRNmEPQ18qZlLowV@nathan>
 <CAApHDvrtvMF3_W69hOUr2SnbizjC1jc68_Ca0nPYr=+VUkUkAw@mail.gmail.com>
 <aROY-MUVO_mYTl2f@nathan>
 <CAApHDvpo3YxiaP123vghHL-aLkY2vc-e1scpDSpaTFWz1qVaQA@mail.gmail.com>
 <CABV9wwOcD4RM5Hm0d+=KBK8LyHLtEtF3YZ4ak8V3VvOYV9Z4Tw@mail.gmail.com>
 <aRTpqMleDpoQm9OO@nathan>
In-Reply-To: <aRTpqMleDpoQm9OO@nathan>
From: Sami Imseih <samimseih@gmail.com>
Date: Wed, 12 Nov 2025 16:10:22 -0600
Message-ID: 
 <CAA5RZ0uf31FQ41udQGL91sp3GdaLqcbwO103Q-zJQcJowq7fEw@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Robert Treat <rob@xzilla.net>, David Rowley <dgrowleyml@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
 Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0uf31FQ41udQGL91sp3GdaLqcbwO103Q-zJQcJowq7fEw%40mail.gmail.com>
Precedence: bulk

> I do think re-prioritization is worth considering, but IMHO we should lea=
ve
> it out of phase 1.  I think it's pretty easy to reason about one round of
> prioritization being okay.  The order is completely arbitrary today, so h=
ow
> could ordering by vacuum-related criteria make things any worse?

While it=E2=80=99s true that the current table order is arbitrary, that arb=
itrariness
naturally helps distribute vacuum work across tables of various sizes
at a given time

The proposal now is by design forcing all the top bloated table, that
will require more I/O to vacuum to be vacuumed at the same time,
by all workers. Users may observe this after they upgrade and wonder
why their I/O profile changed and perhaps slowed others non-vacuum
related processing down. They also don't have a knob to go back to
the previous behavior.

Of course, this behavior can and will happen now, but with this
prioritization, we are forcing it.

Is this a concern?

--
Sami Imseih
Amazon Web Services (AWS)