Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id adE9RbcA7lhH_w2d@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 10:32:07AM -0500, Sami Imseih wrote:
>> On Sat, Apr 04, 2026 at 08:25:26AM -0500, Sami Imseih wrote:
>> > "Scores greater than or equal to <literal>1.0</literal>" in the comments
>> > of each field are misleading. This conflates scoring with vacuum/analyze
>> > eligibility and it's possible with a autovacuum_*_weight < 1.0 to trigger an
>> > autovacuum/analyze.
>>
>> Ah, that's unfortunate.  I think it'd be good to give folks some idea of
>> what autovacuum will actually process.  I wonder if we could adjust the
>> documentation accordingly.
> 
> That's why I thought having the bool fields made sense in the earlier
> versions of the view. Since autovacuum is dealing with 2 concepts:
> 
> eligibility: is av enabled and is the table meeting thresholds
> score: The priority of how the eligible tables will be processed.
> 
> So, while this could be explained in docs, I think it's better we report
> these fields.

I understand your position, but I still worry about potential confusion if
when dovacuum and needs_vacuum differ.  And I don't know how much we really
ought to be tailoring this stuff to clusters where autovacuum is disabled
or where the scores are being adjusted.  Also, I think we ought to go into
more detail in the documentation, anyway.  So my instinct was to do
something more like the attached.

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.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Better shared data structure management and resizable shared data structures
Next
From: Heikki Linnakangas
Date:
Subject: Re: Better shared data structure management and resizable shared data structures