Hi, On Tue, Mar 24, 2026 at 10:15 AM Nathan Bossart <[email protected]> wrote: > > Agreed. Here's a first try at that. I also updated the DEBUG3 at the end > of relation_needs_vacanalyze() to show the individual scores. The comment > above that function might need some work, and we might need a bit of > additional commentary elsewhere.
Sorry for the late response. Thank you for sending the latest patch. +1 for getting the main patch in first and then the scoring stats view. I looked closely at the v15 patch today and it LGTM. A couple of thoughts (I don't intend to block the main patch from getting in :)): 1/ If a large bloated table scores highest and takes hours to vacuum, other tables' XID ages keep advancing (not to the failsafe limits yet, but approaching close to them). By the time the autovacuum worker finishes, a table that now needs freezing is still stuck at its old position in the sorted table list. Would it make sense to recompute scores and re-sort the remaining table list after each table is processed in do_autovacuum()'s main loop - say, after a certain amount of time spent vacuuming the large table(s)? This would catch the above scenarios. I see that the scores per table are being calculated in relation_needs_vacanalyze, but they are ignored in the recheck path (table_recheck_autovac -> recheck_relation_needs_vacanalyze -> relation_needs_vacanalyze). IMHO, this could be a useful future addition. 2/ Nit: IIUC, autovacuum_vacuum_score_weight and other existing vacuum thresholds and scale factor GUCs are the ones to tune to make the tables prioritized first. I still think it would be nice to have a document explaining these scenarios - maybe after the main patch gets in. -- Bharath Rupireddy Amazon Web Services: https://aws.amazon.com
