From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(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-21 22:43:40 |
Message-ID: | CAAKRu_ZQe26xdvAqo4weHLR=ivQ8J4xrSfDDD8uXnh-O-6P6Lg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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).
I do agree that logging the number of empty pages vacuum rediscovered
could be useful (maybe in a "freespace" prefixed line about freespace
and empty pages vacuum found). But, I don't think that is a reason not
to add VM updates to the vacuum log output.
So, after all of the discussion on this thread, I propose the existing
vacuum log output (as on master) with the addition of one line about
pages newly set all-visible/all-frozen by this vacuum:
visibility map: 5 pages set all-visible, 4 pages set all-frozen.
- Melanie
[1] https://www.postgresql.org/message-id/flat/CAAKRu_ZF_KCzZuOrPrOqjGVe8iRVWEAJSpzMgRQs%3D5-v84cXUg%40mail.gmail.com
[2] https://www.postgresql.org/message-id/ctdjzroezaxmiyah3gwbwm67defsrwj2b5fpfs4ku6msfpxeia%40mwjyqlhwr2wu
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2024-11-21 22:46:50 | Re: SQL:2023 JSON simplified accessor support |
Previous Message | Nathan Bossart | 2024-11-21 22:34:44 | Re: Use __attribute__((target(sse4.2))) for SSE42 CRC32C |