Re: Eager page freeze criteria clarification - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Eager page freeze criteria clarification
Date
Msg-id CA+TgmoaCZNUxLYw+HxhyGosArdcKOX6ptFM+zKipmRQtPJkkFg@mail.gmail.com
Whole thread Raw
In response to Re: Eager page freeze criteria clarification  (Melanie Plageman <melanieplageman@gmail.com>)
List pgsql-hackers
On Thu, Oct 12, 2023 at 11:50 AM Melanie Plageman
<melanieplageman@gmail.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



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Next
From: Robert Haas
Date:
Subject: Re: Wait events for delayed checkpoints