Feedback-ID: ia2694551:Fastmail
Date: Mon, 3 Mar 2025 17:44:54 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Add relallfrozen to pg_class
Message-ID: <202503031644.nihftaytey2b@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E1tp8XG-000baq-1b@gemulon.postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/202503031644.nihftaytey2b%40alvherre.pgsql>
Precedence: bulk

On 2025-Mar-03, Melanie Plageman wrote:

> Add relallfrozen to pg_class
> 
> Add relallfrozen, an estimate of the number of pages marked all-frozen
> in the visibility map.
> 
> pg_class already has relallvisible, an estimate of the number of pages
> in the relation marked all-visible in the visibility map. This is used
> primarily for planning.
> 
> relallfrozen, together with relallvisible, is useful for estimating the
> outstanding number of all-visible but not all-frozen pages in the
> relation for the purposes of scheduling manual VACUUMs and tuning vacuum
> freeze parameters.

I'm confused about this.  Why was the new value added to pg_class
instead of to the pgstat system?  I don't think relallvisible is a good
precedent, because as you write here, that one is used for planning,
which has different requirements.  For vacuuming metrics we rely on
pgstat.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)