Re: Count and log pages set all-frozen by vacuum

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nitin Jadhav <nitinjadhavpostgres(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 20:37:43
Message-ID: CAAKRu_bvV7MBkTyyYRtQzG3J3odow73BXs+utxZfvUzDLTxPww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 26, 2024 at 1:55 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> 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?".

Ah, good point. With a spin on the earlier example:

create table foo (a int, b int) with (autovacuum_enabled = false);
insert into foo select generate_series(1,1000), 1;
delete from foo where a > 500;

vacuum (verbose) foo;
visibility map: 5 pages set all-visible, 2 pages set all-frozen.

5 pages were set all-visible and, of those, 2 were set all-frozen. So,
3 were set only all-visible. This is like (b) in your description.

However, now if we do:

vacuum (verbose, freeze) foo;
visibility map: 0 pages set all-visible, 3 pages set all-frozen.

Here, 3 already all-visible pages were set all-frozen.
This does currently tell you the number of bits newly set, not the
number of pages' whose VM status changed state.

In fact, you could have a case where it is even more difficult to tell
the total number of pages' whose VM status was updated. Let's say the
first vacuum sets 5 pages newly all-visible, and of those, 2 are set
all-frozen. Separately, 2 all-visible pages elsewhere in the relation
are scanned (say due to SKIP_PAGES_THRESHOLD) and are old enough to
require freezing. The message would be:

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

But, we know 2 pages were set all-visible and all-frozen, 3 were set
only all-visible, and 2 all-visible pages were set all-frozen. That's
seven pages changing state. You would have no idea how many total
pages changed state from the log message.

So, since the transitions that are possible here are:
nothing -> all-visible
nothing -> all-visible and all-frozen
all-visible -> all-visible and all-frozen

What if we changed the message to reflect these state changes:

visibility map: 5 pages newly set all-visible, of which 2 set
all-frozen. 2 all-visible pages newly set all-frozen.

- Melanie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2024-11-26 20:46:43 Re: Fix meson uuid header check so it works with MSVC in REL_16_STABLE
Previous Message Thomas Munro 2024-11-26 20:24:54 Re: On non-Windows, hard depend on uselocale(3)