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