Re: Eagerly scan all-visible pages to amortize aggressive vacuum

Hi,

On 2025-01-07 15:46:26 -0500, Melanie Plageman wrote:
> For table storage options, those related to vacuum but not autovacuum
> are in the main StdRdOptions struct. Of those, some are overridden by
> VACUUM command parameters which are parsed out into the VacuumParams
> struct. Though the members of VacuumParams are initialized in
> ExecVacuum(), the storage parameter overrides are determined in
> vacuum_rel() and the final value goes in the VacuumParams struct which
> is passed all the way through to heap_vacuum_rel().
>
> Because VacuumParams is what ultimately gets passed down to the
> table-AM specific vacuum implementation, autovacuum also initializes
> its own instance of VacuumParams in the autovac_table struct in
> table_recheck_autovac() (even though no VACUUM command parameters can
> affect autovacuum). These are overridden in vacuum_rel() as well.
>
> Ultimately vacuum_eager_scan_max_fails is a bit different from the
> existing members of VacuumParams and StdRdOptions. It is a GUC and a
> table storage option but not a SQL command parameter -- and both the
> GUC and the table storage parameter affect both vacuum and autovacuum.
> And it doesn't need to be initialized in different ways for autovacuum
> and vacuum. In the end, I decided to follow the existing conventions
> as closely as I could.

I think that's fine. The abstractions in this area aren't exactly perfect, and
I don't think this makes it worse in any meaningful way. It's not really
different from having other heap-specific params like freeze_min_age in
VacuumParams.

Greetings,

Andres Freund