> >> If we did report booleans, I would probably argue for just reporting > >> dovacuum and doanalyze and calling out the criteria for why they may be > >> false even when it looks like the table needs processing. > > > > Yes, we only require a needs_analyze and needs_vacuum. The latter > > can be set to true due to thresholds or wraparound. But, I don't think we > > should rely on the dovacuum or doanalyze, instead we can just have a flag > > in AutoVacuumScores->needs and track what is needed. This will separate > > the autovacuum processing from the reporting. > > Sorry for going in circles about this, but I'm not seeing why we wouldn't > just return the booleans that relation_needs_vacanalyze() already returns. > I think the question people will have is "what will autovacuum process and > in what order?", and if we aren't giving them the exact same information > that autovacuum is using to make its decisions, then I'm not sure what is > the point. It's true that someone might disable autovacuum for a table and > that it would otherwise be processed, but so be it.
Maybe there’s no need to worry too much about the autovacuum disabled case or track_counts being disabled when querying the view. Both are edge cases, and it seemed fairly trivial to compensate for this with what I had attached earlier. Anyhow, I will not push this point further. I am ok with proceeding with what you have in v12. The patches overall LGTM. Thanks! -- Sami
