Horton
Menu

Re: Add pg_stat_autovacuum_priority

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Robert Treat <rob@xzilla.net>, satyanarlapuram@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-04T17:48:28Z
Lists: pgsql-hackers

Attachments

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

After looking at it a bit more, I don't think we can avoid putting
the needs_analyze and needs_vacuum fields, because without them
there will still be a gap in understanding of if a table is eligible for
autovacuum. A score on its own will not draw the full picture. For example,
if I tune the _weight settings, I want to know if this table now becomes
a candidate for vacuum/analyze, irrespective if autovacuum will actually
process it due to some bad configuration. I can see someone seaching
this view by just the bool fields to see the eligibile tables also without
caring about the score.

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

Here is what I am thinking we should do.

v11-0001 is same as v10-0001
v11-0002 introduces the additional bit field for reporting. This sets the
need for vacuum regardless of av_enabled.
v11-0003 the view with slightly more detailed documentation.

--
Sami

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix double-free in pg_stat_autovacuum_scores.

  2. Add LOG_NEVER error level code.

  3. Add pg_stat_autovacuum_scores system view.

  4. Remove recheck_relation_needs_vacanalyze().

  5. Add elevel parameter to relation_needs_vacanalyze().

  6. Teach relation_needs_vacanalyze() to always compute scores.

  7. Refactor relation_needs_vacanalyze().

  8. Add rudimentary table prioritization to autovacuum.

  9. Fix per-relation memory leakage in autovacuum.

  10. Fix recently-understood problems with handling of XID freezing, particularly