Re: Eager page freeze criteria clarification

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie>, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: Eager page freeze criteria clarification
Date: 2023-10-12 17:28:57
Message-ID: CA+TgmoaCZNUxLYw+HxhyGosArdcKOX6ptFM+zKipmRQtPJkkFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 12, 2023 at 11:50 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> I was under the impression that we decided we still had to consider
> the number of clean pages dirtied as well as the number of pages
> unfrozen. The number of pages frozen and unfrozen over a time period
> gives us some idea of if we are freezing the wrong pages -- but it
> doesn't tell us if we are freezing the right pages. A riff on an
> earlier example by Robert:
>
> While vacuuming a relation, we freeze 100 pages. During the same time
> period, we modify 1,000,000 previously clean pages. Of these 1,000,000
> pages modified, 90 were frozen. So we unfroze 90% of the pages frozen
> during this time. Does this mean we should back off of trying to
> freeze any pages in the relation?

I didn't think we decided the thing your first sentence says you
thought we decided ... but I also didn't think of this example. That
said, it might be fine to back off freezing in this case because we
weren't doing enough of it to make any real difference in the first
place. Maybe there's a more moderate example where it feels like a
bigger problem?

> > - "Number of pages frozen during vacuum" and "Number of pages unfrozen that
> > were frozen during the same vacuum" provides numerator / denominator for
> > an "error rate"
> >
> > - We can perform this attribution by comparing the page LSN with recorded
> > start/end LSNs of recent vacuums
>
> While implementing a rough sketch of this, I realized I had a question
> about this.
>
> vacuum 1 starts at lsn 10 and ends at lsn 200. It froze 100 pages.
> vacuum 2 then starts at lsn 600.
> 5 frozen pages with page lsn > 10 and < 200 were updated. We count
> those in vacuum 1's stats. 3 frozen pages with page lsn > 200 and <
> 600 were updated. Do we count those somewhere?

How did those pages get frozen when no VACUUM was running?

The LSN of the frozen page just prior to unfreezing it should be from
the operation that froze it, which should be some VACUUM. I think the
case you're talking about could happen if we did on-access freezing,
but today I believe we don't.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2023-10-12 17:32:29 Re: Wait events for delayed checkpoints
Previous Message David G. Johnston 2023-10-12 17:24:17 Re: Pro et contra of preserving pg_proc oids during pg_upgrade