MIME-Version: 1.0
References: 
 <CAApHDvpnR5zKb7LSB0idj4RPsV+=Dhtk+c5H0cZ4evN2hFDwCQ@mail.gmail.com>
 <3ca1e398-c787-47e9-9afc-8e298b94dac0@app.fastmail.com>
 <abwbDTu6OO6Izp4o@nathan>
 <CAA5RZ0s7k6yve1Bq1OY+aXU3ifc_fvOiYkpE2VxwrUcHr2AtTg@mail.gmail.com>
 <CAApHDvpvkKYB6z-i1kiO9iePF0fz18-CaS9DZEWnSx1eO0RGFQ@mail.gmail.com>
 <CAA5RZ0tPvWLVXhDMC3t3LhwTM-OnWHSvPo7tnZzOphR=HB4kgQ@mail.gmail.com>
 <ab2uoj5yU8CVUJ_H@nathan>
 <CALj2ACV0HboeYiT1Z-=rb509WL3N0H9LsWRPqc_xUMEM-TM85g@mail.gmail.com>
 <acFan6knPZljm1Ay@nathan>
 <CAA5RZ0tz55uoQfcvLwvRWRPM0ry6SGfZ=-enQ4F0kaUgfPh+Vg@mail.gmail.com>
 <acGqIhkP6xo4Vv1l@nathan>
In-Reply-To: <acGqIhkP6xo4Vv1l@nathan>
From: Jim Nasby <jnasby@upgrade.com>
Date: Mon, 23 Mar 2026 17:27:31 -0500
Message-ID: 
 <CAMFBP2q-oMzpEua9Hdcpag15VGZn7aEO-uaHZ4yVEO_HCm55_Q@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	David Rowley <dgrowleyml@gmail.com>, Greg Burd <greg@burd.me>,
 Robert Haas <robertmhaas@gmail.com>,
	Robert Treat <rob@xzilla.net>, Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000926bb064db88bd3"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMFBP2q-oMzpEua9Hdcpag15VGZn7aEO-uaHZ4yVEO_HCm55_Q%40mail.gmail.com>
Precedence: bulk

--0000000000000926bb064db88bd3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 23, 2026 at 4:01=E2=80=AFPM Nathan Bossart <nathandbossart@gmai=
l.com>
wrote:

> On Mon, Mar 23, 2026 at 02:01:22PM -0500, Sami Imseih wrote:
> > Adding a system view will be nice. I am attaching a version I used in
> earlier
> > testing (cleaned up with docs), if we are inclined to get this in. I
> > think it will be
> > useful.
>
> Thanks.  IMHO we should continue to focus on the main patch and get that
> committed first.
>

+1 ... for one thing if we're going to add a view meant for monitoring
autovac decisions I'd like to think about ways to measure how many tables
are "close" to being eligible for autovac. In particular, the scenario
where you've just done an MVU via some form of logical, so now the freeze
ages on all your tables are extremely similar.

It might be nice if we had an official means of publishing things that
we'd really like users to kick the tires on, but hold a clear understanding
that we promise no backwards compatibility, promise we'll keep supporting,
etc. I can't see how that'd work with backend code, but could certainly be
done for anything in userspace.

--0000000000000926bb064db88bd3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Mar 23, 2026 at 4:01=E2=80=AFPM N=
athan Bossart &lt;<a href=3D"mailto:nathandbossart@gmail.com">nathandbossar=
t@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_conta=
iner"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 23, 202=
6 at 02:01:22PM -0500, Sami Imseih wrote:<br>
&gt; Adding a system view will be nice. I am attaching a version I used in =
earlier<br>
&gt; testing (cleaned up with docs), if we are inclined to get this in. I<b=
r>
&gt; think it will be<br>
&gt; useful.<br>
<br>
Thanks.=C2=A0 IMHO we should continue to focus on the main patch and get th=
at<br>
committed first.<br></blockquote><div><br></div><div>+1 ... for one thing i=
f we&#39;re going to add a view meant for monitoring autovac decisions I=
9;d like to think about ways to measure how many tables are &quot;close&quo=
t; to being eligible for autovac. In particular, the scenario where you&#39=
;ve just done an MVU via some form of logical, so now the freeze ages on al=
l your tables are extremely similar.</div><div><br></div><div>It might be n=
ice if we had an official means of publishing things that we&#39;d=C2=A0rea=
lly like users to kick the tires on, but hold a clear understanding that we=
 promise no backwards compatibility, promise we&#39;ll keep supporting, etc=
. I can&#39;t see how that&#39;d work with backend code, but could certainl=
y be done for anything in userspace.</div></div></div>

--0000000000000926bb064db88bd3--