Date: Wed, 18 Mar 2026 11:09:31 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	Robert Treat <rob@xzilla.net>,
	Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Subject: Re: another autovacuum scheduling thread
Message-ID: <abrOO8GCgkhMXvcq@nathan>
References: <abAzhNqs5F8sJDdm@nathan>
 <abBEiOICOdbbhsEI@nathan>
 <CAA5RZ0seLxDmH9UftUA3vS8DrW+7T9HV5XK8yAuQxA8BaRkg2g@mail.gmail.com>
 <CAA5RZ0vfhAnFBp4HrBQc+ALaJMx6vCvMtnBi39ST_4nH9PZEjA@mail.gmail.com>
 <abGP87A3JPIXDG2I@nathan>
 <CAA5RZ0tWonKY=E5U51i-J8s2EcRoLqtUQyWv+pQ4_rjFKSn+AA@mail.gmail.com>
 <abGmNAVIPSqX124E@nathan>
 <CAA5RZ0sZE-gfJ0c9HJkOk9XeFQwZL2wuJwrtOX+ZfUBLDcpFMA@mail.gmail.com>
 <abMR6MQGQyyKWep4@nathan>
 <CAApHDvqHXYCb=x0hHeR1e21ksqFNk4q3_zoPk6V-LLu0VL491Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="IwjnQr02zhZ5zNSb"
Content-Disposition: inline
In-Reply-To: 
 <CAApHDvqHXYCb=x0hHeR1e21ksqFNk4q3_zoPk6V-LLu0VL491Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/abrOO8GCgkhMXvcq%40nathan>
Precedence: bulk


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

On Wed, Mar 18, 2026 at 12:06:34PM +1300, David Rowley wrote:
> I think it would have been better to have done this about 3 months
> ago, but I think it's probably still fine to do now. Feature freeze is
> still quite a long way from release. I do expect that the most likely
> time that someone would find issues with this change would be during
> beta or RC, as that's when people would give PostgreSQL production
> workloads to try out. During the dev cycle, I expect it's *mostly*
> just hackers giving the database toy workloads in a very targeted way
> to something specific that they're hacking on.  Anyway, now since
> you've added the GUCs to control the weights, there's a way for users
> to have some influence, so at least there's an escape hatch.

Thanks for chiming in.

> I think the GUCs are probably a good idea. I expect the most likely
> change that people might want to make would be to raise the priority
> of analyze over vacuum since that's often much faster to complete. We
> know that some workloads are very sensitive to outdated statistics.
> 
> On the other hand, we shouldn't be taking adding 5 new autovacuum GUCs
> lightly as there are already so many. If we are going to come up with
> something better than this in a few years then it could be better to
> wait to reduce the pain of having to remove GUCs in the future. I
> don't personally have any better ideas, so I'd rather see it go in
> than not.

Yeah, adding these GUCs feels a bit like etching in stone, but if folks
want configurability, and nobody has better ideas, I'm not sure what else
to do.

> I didn't look at the patch in detail, but noticed that you might want
> to add a "See Section N.N.N for more information." to the new GUCs to
> link to the text you've added on how they're used.

Good idea.  I've added that.

> Do you think it's worth making the call to
> list_sort(tables_to_process, TableToProcessComparator) conditional on
> a variable set like: sort_required |= (score != 0.0);? I recall that
> someone had concerns that the actual sort itself could add overhead.

I don't think it's necessary.  I tested sorting 1M and 10M tables with
randomly generated scores (on my MacBook, with assertions enabled).  The
former took ~150 milliseconds, and the latter took ~1770 milliseconds.  I
suspect there are far bigger problems to worry about if you have anywhere
near that many tables.

-- 
nathan

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