Re: another autovacuum scheduling thread

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: another autovacuum scheduling thread
Date: 2026-03-11 17:59:05
Message-ID: CAA5RZ0sZE-gfJ0c9HJkOk9XeFQwZL2wuJwrtOX+ZfUBLDcpFMA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> On Wed, Mar 11, 2026 at 12:08:52PM -0500, Sami Imseih wrote:
> > The main issue is that the scores can reach quadrillions, or even
> billions,
> > which feels excessive, especially if exposed in DEBUG3 or in a future
> > prioritization view.
>
> But why is that an issue? Because the number looks big when there's
> extremely verbose logging enabled? I'm not following your objection.

Yes, purely the looks of such an excessively large number could look wrong
to a user.
Putting on my user hat, I would be confused and honestly think this is a
bug in the
calculation. If we weren’t exposing the numbers, I would not care.

But, this could just be me.

This comment "this component increases greatly once the age surpasses" is
perhaps
good enough.

we _want_ the score to be excessively high in these cases so that there's
> basically zero chance a table with unreasonable bloat takes priority. This
> was discussed a bit upthread [0].
>
> [0]
> https://postgr.es/m/CAApHDvqrd%3DSHVUytdRj55OWnLH98Rvtzqam5zq2f4XKRZa7t9Q%40mail.gmail.com
>

Yes, I definitely agree with this.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-03-11 18:03:28 Re: Defend against -ffast-math in meson builds
Previous Message Bertrand Drouvot 2026-03-11 17:54:33 Re: Defend against -ffast-math in meson builds