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

From Alastair Turner
Subject Re: Count and log pages set all-frozen by vacuum
Date
Msg-id CAC0Gmyx9b_6mZ8UUZnPYNU5scJvUOU3En=+J8ni7+5FDRTZG0w@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, 31 Oct 2024 at 18:51, Melanie Plageman <melanieplageman@gmail.com> wrote:

Would it also be useful to have the number set all-visible? It seems
like if we added a new line prefixed with visibility map, it ought to
include all-visible and all-frozen then.
Something like this:
 visibility map: %u pages set all-visible, %u pages set all-frozen.

I find it more confusing to say "up to X may have been removed from
the table." It's unclear what that means -- especially since we
already have "pages removed" in another part of the log message.
 
Yeah, on looking at it again, that does seem to make things worse.

We actually could call visibilitymap_count() at the beginning of the
vacuum and then log the difference between that and the results of
calling it after finishing the vacuum. We currently call it after
truncating the table anyway. That won't tell you how many pages were
set all-frozen by this vacuum, as pages could have been unfrozen by
DML that occurred after the page was vacuumed. It might be useful in
addition to the line about the visibility map.

This is somewhat in conflict with Robert and Peter's points about how
autovacuum logging should be about what this vacuum did. But, we do
have lines that talk about the before and after values:

new relfrozenxid: 748, which is 3 XIDs ahead of previous value

So, we could do something like:
visibility map before: %u pages all-visible, %u pages all-frozen
visibility map after: %u pages all-visible, %u pages all-frozen
or
visibility map after: %u pages all-visible (%u more than before), %u
pages all-frozen (%u more than before)

I still prefer adding how many pages were set all-frozen by this vacuum, though.

I also like the idea of showing how many pages were set all-frozen by this vacuum (which meets Robert's requirement for figuring out if a vacuum operation did anything useful). The values for pages marked all visible and all frozen can fluctuate for a number of reasons, even, as you point out, from concurrent activity during the vacuum. This is different from relfrozenxid which is a kind of high water mark. So I think the output styles can reasonably be different.

visibility map: %u pages all-visible (%u marked by this operation), %u pages all-frozen (%u marked by this operation)

seems to support everyone's requirements

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Time to add a Git .mailmap?
Next
From: Robert Haas
Date:
Subject: Re: Eager aggregation, take 3