Date: Wed, 11 Mar 2026 10:53:23 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	David Rowley <dgrowleyml@gmail.com>, Robert Treat <rob@xzilla.net>,
	Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Subject: Re: another autovacuum scheduling thread
Message-ID: <abGP87A3JPIXDG2I@nathan>
References: 
 <CA+TgmoZE=-Pw=85u+eX6UpMdY02o1otEhQba0n2T78yVyV2N9g@mail.gmail.com>
 <CAA5RZ0vzu4vfRP0podGDCBOn-OaK9Qs-oyksER5OtzanacqMQw@mail.gmail.com>
 <CA+TgmoZ44jzFBB4zxoXrX6iMxv7TPzv5duPe44UPpoyBBDL48g@mail.gmail.com>
 <CAApHDvo97hqpZR+vgVVSLQsPhVCA=yEerAGn9wzB_67vjmu6cA@mail.gmail.com>
 <CA+TgmoaAgv5D6u+_4KKqQFGH1n+jsFZ1mFWh+CSGqDUtyBNsXg@mail.gmail.com>
 <aam3dmZcia95-vB6@nathan>
 <abAzhNqs5F8sJDdm@nathan>
 <abBEiOICOdbbhsEI@nathan>
 <CAA5RZ0seLxDmH9UftUA3vS8DrW+7T9HV5XK8yAuQxA8BaRkg2g@mail.gmail.com>
 <CAA5RZ0vfhAnFBp4HrBQc+ALaJMx6vCvMtnBi39ST_4nH9PZEjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nNr1ltPzm3pWzSNb"
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0vfhAnFBp4HrBQc+ALaJMx6vCvMtnBi39ST_4nH9PZEjA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/abGP87A3JPIXDG2I%40nathan>
Precedence: bulk


--nNr1ltPzm3pWzSNb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--nNr1ltPzm3pWzSNb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v11-0001-autovacuum-scheduling-improvements.patch