> >> 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
