Re: pgsql: Add relallfrozen to pg_class

From: Andres Freund <andres(at)anarazel(dot)de>
To: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add relallfrozen to pg_class
Date: 2025-03-03 16:50:21
Message-ID: spdyfkaiav3uzq6qpfiezhqav2x7sqen5i74da2uittljo3z56@br2kogkjyvej
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Hi,

On 2025-03-03 17:44:54 +0100, Álvaro Herrera wrote:
> 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.

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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Melanie Plageman 2025-03-03 16:52:40 Re: pgsql: Add relallfrozen to pg_class
Previous Message Melanie Plageman 2025-03-03 16:48:18 Re: pgsql: Add relallfrozen to pg_class