> On Fri, 24 Oct 2025 at 08:33, Sami Imseih <samimseih@gmail.com> wrote:
> > Yeah, you’re correct, the list already exists; sorry I missed that. My
> > main concern is
> > the additional overhead of the sort operation, especially if we have
> > many eligible
> > tables and an aggressive autovacuum_naptime.
>
> It is true that there are reasons that millions of tables could
> suddenly become eligible for autovacuum work with the consumption of a
> single xid, but I imagine sorting the list of tables is probably the
> least of the DBAs worries for that case as sorting the
> tables_to_process list is going to take a tiny fraction of the time
> that doing the vacuum work will take.
Yes, in my last reply, I did indicate that the sort will likely not be
the operation that will tip the performance over, but the
catalog scan itself that I have seen not scale well as the number of
relations grow ( in cases of thousands or hundreds of thousands of tables).
If we are to prioritize vacuuming by M(XID), then it will be hard to avoid the
catalog scan anymore in a future improvement.
>TBH, I think that mindset has likely contributed quite a
> bit to the fact that we've made about zero improvements in this area
> despite nobody thinking that nothing needs to be done.
I am not against this idea, just thinking out loud about the high relation
cases I have seen in the past.
--
Sami
