From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alastair Turner <minion(at)decodable(dot)me>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Count and log pages set all-frozen by vacuum |
Date: | 2024-11-26 18:55:05 |
Message-ID: | CAD21AoBg02iCSxibHOzf4+n1pXhyBH0eR4htoQP1BqXv8SxTnQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 21, 2024 at 2:43 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> On Fri, Nov 1, 2024 at 5:39 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2024-11-26 19:04:15 | Re: Doc: typo in config.sgml |
Previous Message | Tom Lane | 2024-11-26 18:24:35 | Re: Potential ABI breakage in upcoming minor releases |