Re: Add pg_stat_autovacuum_priority

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(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 15:32:07
Message-ID: CAA5RZ0vxby2osMMaCuZ=680tmt583cF9n4rOzTGdsiS-1PJknA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

We might as well just call the view pg_stat_autovacuum in that case.

What do you think?

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-04-04 15:38:24 Re: TupleDescAttr bounds checks
Previous Message Antonin Houska 2026-04-04 15:29:19 Re: Adding REPACK [concurrently]