HI Nathan > That approach would begin aggressively scaling the priority of tables > sooner, but I don't know if that's strictly better. In any case, I'd like > to avoid making the score calculation too magical. In fact, with the introduction of the vacuum_max_eager_freeze_failure_rate feature, if a table’s age still exceeds more than 1.x times the autovacuum_freeze_max_age, it suggests that the vacuum freeze process is not functioning properly. Once the age surpasses vacuum_failsafe_age, wraparound issues are likely to occur soon.Taking the average of vacuum_failsafe_age and autovacuum_freeze_max_age is not a complex approach. Under the default configuration, this average already exceeds four times the autovacuum_freeze_max_age. At that stage, a DBA should have already intervened to investigate and resolve why the table age is not decreasing.
Thanks On Thu, Oct 30, 2025 at 12:07 AM Nathan Bossart <[email protected]> wrote: > 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 > > >
