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: Robert Treat <rob@xzilla.net>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, satyanarlapuram@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-31T16:41:08Z
Lists: pgsql-hackers 
> >> I also see that we're not forcing the computation of the (M)XID
> >> scores.  Is that intentional?
> >
> > hmm, the force_score does not need to be in the force_vacuum path
> > because the score is calculated there naturally when the table is in
> > need of force_vacuum. The force_score is there to ensure that
> > we are not existing early in the autovacuum disabled case.
>
> So, unless the table is beyond a freeze-max-age parameter, the (M)XID
> scores will always be 0.0?

You're right after thinking about this again. There is no reason why we
should treat the force_vacuum case differently. The score should still
be included so someone monitoring can see the xid|mxid_age climbing
well before it becomes an issue.

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