Re: Count and log pages set all-frozen by vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Count and log pages set all-frozen by vacuum
Date
Msg-id CAD21AoBg02iCSxibHOzf4+n1pXhyBH0eR4htoQP1BqXv8SxTnQ@mail.gmail.com
Whole thread Raw
In response to Re: Count and log pages set all-frozen by vacuum  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Count and log pages set all-frozen by vacuum
List pgsql-hackers
On Thu, Nov 21, 2024 at 2:43 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > I think we agreed with what the patches proposed by Melanie do, so
> > let's focus on these patches on this thread. We can add other
> > information later if we need.
>
> Thanks for the feedback and input.
> So, currently what I have is a line for updates to the visibility map:
>
> visibility map: 5 pages set all-visible, 4 pages set all-frozen.
>
> Because this patch set is a prerequisite for the work I proposed over
> in [1], Andres happened to review this patch in the course of
> reviewing the larger patch set. He brought up yet a different
> perspective that I hadn't thought of [2]. He says:
>
> > Hm. Why is it interesting to log VM changes separately from the state changes
> > of underlying pages? Wouldn't it e.g. be more intersting to log the number of
> > empty pages that vacuum [re-]discovered? I've a bit hard time seeing how a
> > user could take advantage of this.
>
> I think he is saying that the updates to the VM to set pages
> all-frozen belong with the "frozen" line of vacuum log output:
> frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
>
> Personally, I do think pages set all-visible/all-frozen in the VM is
> interesting to users -- when determining how much useful work a given
> vacuum did.
> And the "frozen" line is really about freezing tuples -- there can be
> pages with newly frozen tuples that aren't set all-frozen in the VM
> and pages set all-frozen in the VM that don't have newly frozen tuples
> (because they are empty).

Just to be clear, do users want the number of updated VM bits or the
number of pages whose visibility information is updated? For example,

> visibility map: 5 pages set all-visible, 4 pages set all-frozen.

IIUC the above log can be interpreted in two ways in terms of the
number of pages:

(a) 5 pages are marked as all-visible, and other 4
(already-marked-as-all-visible) pages are marked as all-frozen. That
is, 9 VM bits for 9 pages in total got updated.
(b) 1 page is marked as all-visible, and other 4 pages are marked as
all-frozen (and all-visible as well).  That is, 9 VM bits for 5 pages
in total got updated.

If users want to know "how many VM bits were updated?", the above log
makes sense. But there is no clear answer to "How many pages were
updated in terms of VM?".

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential ABI breakage in upcoming minor releases
Next
From: Sergey Prokhorenko
Date:
Subject: Re: UUID v7