> If the idea is to never allow parallelism in vacuum, then I think > disabling eager scanning during manual parallel vacuum seems > reasonable. People could use vacuum freeze if they want more freezing.
IIUC the purpose of parallel vacuum is incompatible with the purpose of auto vacuum. The former is aimed to execute the vacuum as fast as possible using more resources, whereas the latter is aimed to execute the vacuum while not affecting foreground transaction processing. It's probably worth considering to enable parallel vacuum even for autovacuum in a wraparound situation, but the purpose would remain the same.
That's assuming that the database is running with autovacuum_cost_delay > 0. There's presumably some number of systems that intentionally do not throttle autovacuum. Another consideration is that people are free to set vacuum_cost_page_miss = 0; in those cases it would still be useful to parallelize at least phase 1 and 2. Of course, folks can also set vacuum_cost_page_dirty = 0, in which case parallelization would help phase 2 and 3.
In terms of less hypothetical scenarios, I've definitely run into cases where 1 table accounts for 90%+ of the space used by a database. Parallelism would help ensure the single table is still processed in a timely fashion. (Assuming non-default settings for vacuum throttling.)
