Re: another autovacuum scheduling thread - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: another autovacuum scheduling thread
Date
Msg-id CAA5RZ0uf31FQ41udQGL91sp3GdaLqcbwO103Q-zJQcJowq7fEw@mail.gmail.com
Whole thread Raw
In response to Re: another autovacuum scheduling thread  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: another autovacuum scheduling thread
List pgsql-hackers
> I do think re-prioritization is worth considering, but IMHO we should leave
> 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 how
> could ordering by vacuum-related criteria make things any worse?

While it’s true that the current table order is arbitrary, that arbitrariness
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)



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Add support for COPY TO in tablesync for partitioned tables.
Next
From: Bryan Green
Date:
Subject: Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain