MIME-Version: 1.0
References: 
 <CAA5RZ0uf31FQ41udQGL91sp3GdaLqcbwO103Q-zJQcJowq7fEw@mail.gmail.com>
 <AFC199A4-423E-4B9C-A6CF-F8EE2163B2C5@ardentperf.com>
In-Reply-To: <AFC199A4-423E-4B9C-A6CF-F8EE2163B2C5@ardentperf.com>
From: Sami Imseih <samimseih@gmail.com>
Date: Wed, 12 Nov 2025 18:32:12 -0600
Message-ID: 
 <CAA5RZ0ufYr0MPQbGy3zsKf8QQpG5KA5++jSEKGJvjNRKsG+Qzg@mail.gmail.com>
Subject: Re: another autovacuum scheduling thread
To: Jeremy Schneider <schneider@ardentperf.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Robert Treat <rob@xzilla.net>,
	David Rowley <dgrowleyml@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000c4c89806436f0393"
Archived-At: 
 <https://www.postgresql.org/message-id/CAA5RZ0ufYr0MPQbGy3zsKf8QQpG5KA5%2B%2BjSEKGJvjNRKsG%2BQzg%40mail.gmail.com>
Precedence: bulk

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

>
> > On Nov 12, 2025, at 5:10=E2=80=AFPM, Sami Imseih <samimseih@gmail.com> =
wrote:
> >
> > =EF=BB=BF
> >>
> >> I do think re-prioritization is worth considering, but IMHO we should
> leave
> >> it out of phase 1.  I think it's pretty easy to reason about one round
> of
> >> prioritization being okay.  The order is completely arbitrary today, s=
o
> how
> >> could ordering by vacuum-related criteria make things any worse?
> >
> > While it=E2=80=99s true that the current table order is arbitrary, that
> arbitrariness
> > naturally helps distribute vacuum work across tables of various sizes
> > at a given time
> >
> > The proposal now is by design forcing all the top bloated table, that
> > will require more I/O to vacuum to be vacuumed at the same time,
> > by all workers. Users may observe this after they upgrade and wonder
> > why their I/O profile changed and perhaps slowed others non-vacuum
> > related processing down. They also don't have a knob to go back to
> > the previous behavior.
> >
> > Of course, this behavior can and will happen now, but with this
> > prioritization, we are forcing it.
> >
> > Is this a concern?
>
> It=E2=80=99s still possible to tune the cost delay, the number of autovac=
uum
> workers, etc - if someone needs to manage too much autovacuum I/O
> concurrency and dialing it back down a little bit. I think that=E2=80=99s=
 sufficient
>

Yes, the need to tune a/v for I/O( lower cost limit, higher cost delay
) will likely be
greater with this change.

--
Sami

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

<div><div class=3D"gmail_quote" dir=3D"auto"></div></div><div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,20=
4)" dir=3D"auto"><br>
&gt; On Nov 12, 2025, at 5:10=E2=80=AFPM, Sami Imseih &lt;<a href=3D"mailto=
:samimseih@gmail.com" target=3D"_blank">samimseih@gmail.com</a>&gt; wrote:<=
br>
&gt; <br>
&gt; =EF=BB=BF<br>
&gt;&gt; <br>
&gt;&gt; I do think re-prioritization is worth considering, but IMHO we sho=
uld leave<br>
&gt;&gt; it out of phase 1.=C2=A0 I think it&#39;s pretty easy to reason ab=
out one round of<br>
&gt;&gt; prioritization being okay.=C2=A0 The order is completely arbitrary=
 today, so how<br>
&gt;&gt; could ordering by vacuum-related criteria make things any worse?<b=
r>
&gt; <br>
&gt; While it=E2=80=99s true that the current table order is arbitrary, tha=
t arbitrariness<br>
&gt; naturally helps distribute vacuum work across tables of various sizes<=
br>
&gt; at a given time<br>
&gt; <br>
&gt; The proposal now is by design forcing all the top bloated table, that<=
br>
&gt; will require more I/O to vacuum to be vacuumed at the same time,<br>
&gt; by all workers. Users may observe this after they upgrade and wonder<b=
r>
&gt; why their I/O profile changed and perhaps slowed others non-vacuum<br>
&gt; related processing down. They also don&#39;t have a knob to go back to=
<br>
&gt; the previous behavior.<br>
&gt; <br>
&gt; Of course, this behavior can and will happen now, but with this<br>
&gt; prioritization, we are forcing it.<br>
&gt; <br>
&gt; Is this a concern?<br>
<br>
It=E2=80=99s still possible to tune the cost delay, the number of autovacuu=
m workers, etc - if someone needs to manage too much autovacuum I/O concurr=
ency and dialing it back down a little bit. I think that=E2=80=99s sufficie=
nt<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;=
border-left-color:rgb(204,204,204)" dir=3D"auto"></blockquote><div dir=3D"a=
uto"><br></div></div><div><div dir=3D"auto">Yes, the need to tune a/v for I=
/O( lower cost limit, higher cost delay )=C2=A0will likely be=C2=A0</div><d=
iv dir=3D"auto">greater with this change<span style=3D"border-color:rgb(0,0=
,0)">.=C2=A0</span></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div=
 dir=3D"auto"><span style=3D"font-size:16px;font-style:normal;font-weight:4=
00;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:no=
rmal;word-spacing:1px;text-decoration:none;float:none;display:inline!import=
ant;color:rgb(117,117,117)">--</span></div></div></div><div><div class=3D"g=
mail_quote" dir=3D"auto"><div dir=3D"auto">Sami=C2=A0</div></div>
</div>

--000000000000c4c89806436f0393--