On Wed, Oct 29, 2025 at 10:24:17AM -0500, Sami Imseih wrote: > I think we do need some documentation about this behavior, which v6 is > still missing.
Would you be interested in giving that part a try? > Another thing I have been contemplating about is the change in prioritization > and the resulting difference in the order in which tables are vacuumed > is what it means for workloads in which autovacuum tuning that was > done with the current assumptions will no longer be beneficial. > > Let's imagine staging tables that get created and dropped during > some batch processing window and they see huge data > ingestion/changes. The current scan will make these less of a priority > naturally in relation to other permanent tables, but with the new priority, > we are making these staging tables more of a priority. Users will now > need to maybe turn off autovacuum on a per-table level to prevent this > scenario. That is just one example. > > What I am also trying to say is should we provide a way, I hate > to say a GUC, for users to go back to the old behavior? or am I > overstating the risk here? It's probably worth testing out this scenario, but I can't say I'm terribly worried. Those kinds of tables are already getting chosen by autovacuum earlier due to reltuples == -1, and this patch will just move them to the front of the list that autovacuum creates. In any case, I'd really like to avoid a GUC or fallback switch here. -- nathan
