Re: Add pg_stat_autovacuum_priority

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, satyanarlapuram(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add pg_stat_autovacuum_priority
Date: 2026-04-04 16:33:09
Message-ID: adE9RbcA7lhH_w2d@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v10-0001-refactor-autovacuum-subroutine-in-preparation-fo.patch text/plain 6.1 KB
v10-0002-add-pg_stat_autovacuum_scores-system-view.patch text/plain 12.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-04-04 17:32:33 Re: Better shared data structure management and resizable shared data structures
Previous Message Ashutosh Bapat 2026-04-04 16:32:47 Re: Better shared data structure management and resizable shared data structures