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-03 16:47:40
Message-ID: ac_vLKVgs4RYK1P-@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 01, 2026 at 06:04:36PM -0500, Sami Imseih wrote:
> Thanks! here is v7

Alright, I've been preparing these for commit. Most changes are cosmetic,
but there are a couple of bigger ones I should note:

* I added a prerequisite patch for relation_needs_vacanalyze() that saves a
level of indentation on a chunk of code. This simplifies 0001 (now 0002) a
bit.

* I noticed that if autovacuum decides to force a vacuum for
anti-wraparound purposes, it might also decide to analyze the table even if
autovacuum is disabled for it. AFAICT this is accidental, but since it's
behaved this way since commit 48188e1621 (2006) [0], I am slightly worried
that this bug may have become a feature. In 0002, I separated this edge
case in the code and added a comment, and I intend to start a new thread
about removing it.

* I removed the booleans in the view in favor of just noting that scores >=
1.0 means the table needs processing. IMHO trying to distinguish
needs_vacuum from do_vacuum is just going to confuse folks more than
anything, and IIUC this information is redundant with "score >= 1.0",
anyway.

* I renamed the view to pg_autovacuum_scores. While some of the
information in the view depends on cumulative statistics, not all of it
does, and what does is quite heavily modified from the original stats. So,
I didn't think the pg_stat_* prefix was appropriate, although I can see how
reasonable people might disagree.

* I considered whether to make the backing function per-table and
ultimately decided against it. The initialization logic is a bit
expensive, and I assume most folks will be interested in the full picture
of the current database. Maybe we could add a per-table function down the
road, but I don't see any strong need for that for now.

I'm planning to commit 0001-0004 this afternoon, assuming cfbot is happy.
I'm hoping to commit 0005 on Monday or Tuesday. Please take a look at v8
if you have time.

[0] https://postgr.es/m/23710.1162661716%40sss.pgh.pa.us

--
nathan

Attachment Content-Type Size
v8-0001-refactor-relation_needs_vacanalyze.patch text/plain 7.1 KB
v8-0002-always-compute-autovacuum-scores.patch text/plain 7.2 KB
v8-0003-add-elevel-parameter-to-relation_needs_vacanalyze.patch text/plain 3.0 KB
v8-0004-refactor-autovacuum-subroutine-in-preparation-for.patch text/plain 3.6 KB
v8-0005-add-pg_stat_autovacuum_scores-system-view.patch text/plain 11.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-04-03 17:13:47 Re: pg_plan_advice
Previous Message Melanie Plageman 2026-04-03 16:45:50 Re: AIO / read stream heuristics adjustments for index prefetching