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
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 |