Subject: pgsql: Add relallfrozen to pg_class

From: Melanie Plageman <[email-masked]>
Date: Mon, 03 Mar 2025 16:20:54 +0000

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.

A future commit will use relallfrozen to trigger more frequent vacuums
on insert-focused workloads with significant volume of frozen data.

Bump catalog version

Author: Melanie Plageman <[email-masked]>
Reviewed-by: Nathan Bossart <[email-masked]>
Reviewed-by: Robert Treat <[email-masked]>
Reviewed-by: Corey Huinker <[email-masked]>
Reviewed-by: Greg Sabino Mullane <[email-masked]>
Discussion: https://postgr.es/m/flat/CAAKRu_aj-P7YyBz_cPNwztz6ohP%2BvWis%3Diz3YcomkB3NpYA--w%40mail.gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/99f8f3fbbc8f743290844e8c676d39dad11c5d5d

Modified Files
--------------
doc/src/sgml/catalogs.sgml                 | 20 ++++++
src/backend/access/heap/vacuumlazy.c       | 18 ++++--
src/backend/catalog/heap.c                 |  2 +
src/backend/catalog/index.c                | 12 +++-
src/backend/commands/analyze.c             | 12 ++--
src/backend/commands/cluster.c             |  5 ++
src/backend/commands/vacuum.c              |  6 ++
src/backend/statistics/relation_stats.c    | 29 +++++++--
src/backend/utils/cache/relcache.c         |  2 +
src/include/catalog/catversion.h           |  2 +-
src/include/catalog/pg_class.h             |  3 +
src/include/commands/vacuum.h              |  1 +
src/test/regress/expected/stats_import.out | 99 +++++++++++++++++++-----------
src/test/regress/sql/stats_import.sql      | 49 ++++++++++-----
14 files changed, 190 insertions(+), 70 deletions(-)

---

From: Álvaro Herrera <[email-masked]>
Date: Mon, 3 Mar 2025 17:44:54 +0100

> relation for the purposes of scheduling manual VACUUMs and tuning vacuum

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)

---

From: Melanie Plageman <[email-masked]>
Date: Mon, 3 Mar 2025 11:48:18 -0500

> which has different requirements.  For vacuuming metrics we rely on

We use relpages and reltuples from pg_class in
relation_needs_vacanalyze() in the same way relallfrozen is being used
here.

If we don't want relallfrozen in pg_class then there is no reason we
wouldn't also move relallvisible out of pg_class too.

- Melanie

---

From: Andres Freund <[email-masked]>
Date: Mon, 3 Mar 2025 11:50:21 -0500

Hi,

> which has different requirements.  For vacuuming metrics we rely on

We do so because updating the other stats would cause too much churn - the
number of dead tuples etc changes rather rapidly. That's not the case
here. Having reliable information after a crash (where we loose pgstats) that
95% of the table is actually frozen, rather than not seems good.

Greetings,

Andres Freund

---

From: Melanie Plageman <[email-masked]>
Date: Mon, 3 Mar 2025 11:52:40 -0500

> relation_needs_vacanalyze() in the same way relallfrozen is being used

Sorry reltuples only (not relpages).

- Melanie