Re: another autovacuum scheduling thread - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: another autovacuum scheduling thread
Date
Msg-id abGP87A3JPIXDG2I@nathan
Whole thread Raw
In response to Re: another autovacuum scheduling thread  (Sami Imseih <samimseih@gmail.com>)
Responses Re: another autovacuum scheduling thread
List pgsql-hackers
On Tue, Mar 10, 2026 at 08:08:26PM -0500, Sami Imseih wrote:
>> +        Oid            xid_age;
>> +        Oid            mxid_age;
>>
>> Is using Oid here intentional? I'm curious why not use uint32 for clarity?

Fixed.

>> The new GUC docs says  "...component of the score...", but without
>> introducing the concept of the prioritization score.
>> I think we should expand a bit more on this topic to help a user
>> understand and tune these more effectively. Attached is my
>> proposal for the docs. I tried to keep it informative without
>> being too verbose, and avoided making specific recommendations.

Good idea.  I put my own spin on it in the attached.  Please let me know
what you think.

> The current scaling calculation for force_vacuum could lead to
> exorbitantly high scores.
> Using DEBUG3 and consume_xids_until(2000000000), notice how the score goes
> from 7.93 to 661828682916018.125 once past failsafe age.
> 
> [...]
> 
> Do you think it will be better to just to add the age to the
> score?

I mean, that's kind of the point.  Once a table surpasses one of the
failsafe thresholds, we want its score to be so exorbitantly high that
autovacuum is all but guaranteed to process it first.  I see no particular
advantage to tempering the score in that case.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Defend against -ffast-math in meson builds
Next
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]