Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id adFiCgN22xJ7Z-oR@nathan
Whole thread Raw
In response to Re: Add pg_stat_autovacuum_priority  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Add pg_stat_autovacuum_priority
List pgsql-hackers
On Sat, Apr 04, 2026 at 12:48:28PM -0500, Sami Imseih wrote:
>> 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.

Concretely, like the attached 0003.  IMHO this feels much more natural than
giving folks booleans that usually represents dovacuum/doanalyze but that
don't in certain cases.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Andres Freund
Date:
Subject: Re: Stack-based tracking of per-node WAL/buffer usage