Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w0Nq6-001rOO-1y for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 17:59:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0Nq4-00AqpT-31 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 17:59:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w0Nq4-00AqpK-1y for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 17:59:21 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w0Nq2-00000002AsS-1IYO for pgsql-hackers@postgresql.org; Wed, 11 Mar 2026 17:59:20 +0000 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b9434f706a2so11132666b.1 for ; Wed, 11 Mar 2026 10:59:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773251957; cv=none; d=google.com; s=arc-20240605; b=kf8UKkD+J31QLGfLyiVchb8qKFaSv43IYSmJ49IgbuoqY5nNUUKRpPa5Xym8aX1rRb Cy9CmiZgAzedRG2USbBvnWVeZyZG+SgEv3h2v7oawErXWH+m4XjLUCGS8yM7QjeBeJ5i eZfSKK/v108qa8OGgO0Su+TFstAwHcTF3iSJtdTI2YfumBeXLczgDmGCPJ5XTUEStkDB Iv63KvG4BnKoets/dpcGRDynyepX0GDvskqps2WU/npyIsaFI57kQVHhsOB89tvspb37 3l2mXx8bVql144A51NkhyqyABcADRPgitxkOuekDqoqbp7awQe2nEhooZym3nmBuOm3q jwcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=JIh2GHdjWEZL7iRoY+747nMZbv6DWR46XCfTZe0nbvg=; fh=lD6LtFScLOOhGDmdtSSt5Mw1dTBOaRYzk7VWfQc1T0A=; b=lVIPtlNdFvpMyu1cWXVnYX3LAqiifGuiZjVpXkqhsCSFLx5p13JCYOGtrG32vbk68X kUh7d85AX785jrGh+BgGO8IBaiIWSB5nFfXKtCyJxD96xVgvwQ82vw2RrJf/asRyIelz M4edkmTeqtf10RhjUdHEU9G11ql6FiTSYwgi4JXk53M3n327xggxkaHDIQL/p14yg2MM UEqhRGA92WavkE4tpC16NperX/Gmhj6i94DbFDrU7KO5YPwB1CZf8H+jJpfmJI30FvOP +Wvxd4s9VDl31RjfWMwPkJtJXIuzqApgl2LPj8qcvJz6SzZIB9AEFU6kkYhv6e/VeVMC FiOw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773251957; x=1773856757; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JIh2GHdjWEZL7iRoY+747nMZbv6DWR46XCfTZe0nbvg=; b=G9cqAiidrJzIX91TMZFQd7DgjB0q8ckQtGANUwtjg68qlcOr64qQNmXpLO6epPF/Yc b7wUIUxjvZlskP1nBgDCGwwooGDWJ3TJEWJnNCT02pImShCphOw9MRCYFph8NbD5MBvK AX8rpHhNdA6FMExui44vgzfC9hyoIwPVdmY3eoS00WBrPUSw1BCQ1Lz9ifqms9fuPz8Y U/9629pB533CDFOzHCKD0zse0gSP0+K9IgGt33jf4FJ+VgZbZYJx698KOq4YWTpn/lPU BGuWT6MxB5KZRmn5hTEdUmNOpLXzCbahNBN3nsfb4Q6RVpvM1gVkgYgbNwpMlqodT0b/ Ve1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773251957; x=1773856757; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JIh2GHdjWEZL7iRoY+747nMZbv6DWR46XCfTZe0nbvg=; b=aACeHTbWkIdCfqgTD/GZGJFW9ZPkuromZyHmOTmcz6AgEBWDkY/tB4RjO9z2GaCreq uD+YmaREnXB8h267ArqOCXhVPv1ZUf5gY9qzi+KFmJI9uhhUkwB+6BB32X6ZkiU6IF6N jZ0TiyFE8BAz6O9IIz8L3YjthLdCwODKa9DHBAdupbEl6Z6gZCaudQ7lhPQIGnYXFnBf RqIFI7MM8rX9vvO/4xZzZ06lx2kZPPOtfcVW4nJMhd89EdRKp0FdYq7nWIFjLp9jeDWq Rs2/97GLORGmD32X6wb0Qcv1UX/iWv0n0pZHKBpZ535JMFANyTHOJai98Jfpg2Coevsn FB0w== X-Forwarded-Encrypted: i=1; AJvYcCUiomzdNdUPxcmYq1AcGGHIZ+TXeF1T6UceyJCpN7tzDBaRA9P5UrhepdZwNMoAlNOe4xG6/D/SHsusu6if@postgresql.org X-Gm-Message-State: AOJu0YxnWLMvqorWvTFODX8MrJSy9hWahtdDoKSYJvI4iZPF2BO3Vtif xdXhs1IGEM9606KpN26PvULfeFfEfhfLfTTWfupimjILTLmHxclbVkJBKBC7nkmKt99+fQuy68x 9/2SspwDes4TjLWD0yLzmZ66y2yHr3po= X-Gm-Gg: ATEYQzyCjrXrmQzSxmJ6emD0haz54owURQK43tgUF8U3FVPuwXyHBMzurLkaX7A6Trk wLi+OYeY+DB0AyjFBBLEkNhpMDJUHFa8NEVAZBgN/qI83JqopI5uLX0dchR0GmY4NcI4x0QTqvU MKZpxu/J5NMuT9KaOS8m5tyQEnsknR27QuBGwC/jYvOu1Je9sKBZFcNfNcgcxD9n4XS8voh4DFn ViHMe08/0T1JDGAVLv2Av4kd9FvEfgoJs9WCHDnspfGOXSqqY1GihYhUAoZzXIx34Ta9OklUHz+ kgK7Uw== X-Received: by 2002:a17:907:8694:b0:b97:23c7:2b5c with SMTP id a640c23a62f3a-b972e24c21dmr210647266b.25.1773251956692; Wed, 11 Mar 2026 10:59:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sami Imseih Date: Wed, 11 Mar 2026 12:59:05 -0500 X-Gm-Features: AaiRm501G1yZ_tz_6jadN1Fk7Ys4yanvwuxXc0j_70R43DRueXZxNnZ8_Zx5XcY Message-ID: Subject: Re: another autovacuum scheduling thread To: Nathan Bossart Cc: Robert Haas , David Rowley , Robert Treat , Jeremy Schneider , pgsql-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000f9d8c6064cc3647a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f9d8c6064cc3647a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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=E2=80=99t 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. Th= is > 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) --000000000000f9d8c6064cc3647a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 bill= ions,
> which feels excessive, especially if exposed in DEBUG3 or in a future<= br> > prioritization view.

But why is that an issue?=C2=A0 Because the number looks big when there'= ;s
extremely verbose logging enabled?=C2=A0 I'm not following your objecti= on.=C2=A0

Yes, purely the looks of such an excessively large number c= ould look wrong to a user.=C2=A0
Putting on my us= er hat, I would be confused and honestly think this is a bug in the=C2=A0
calculation. If we weren=E2=80=99t exposing the numbers, I woul= d not care.=C2=A0

But, this could just be me= .

This comment=C2=A0"this component inc= reases greatly once the age surpasses" is perhaps
good en= ough.

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.=C2=A0= This
was discussed a bit upthread [0].

[0] https:= //postgr.es/m/CAApHDvqrd%3DSHVUytdRj55OWnLH98Rvtzqam5zq2f4XKRZa7t9Q%40mail.= gmail.com

Yes, I definitely agree with this.=C2=A0

--
Sami Imseih
Amazo= n Web Services (AWS)
--000000000000f9d8c6064cc3647a--