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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Alastair Turner <minion(at)decodable(dot)me>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Count and log pages set all-frozen by vacuum
Date: 2024-10-31 15:15:16
Message-ID: CAH2-Wz=uey0HHF-W4MCsoPj=X1pYmmGwtkBXCDWKmh_qQSc9FQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> It seems a better solution would be to find a way to document it or
> phrase it clearly in the log. It is true that these pages were set
> all-frozen in the VM. It is just that some of them were later removed.
> And we don't know which ones those are. Is there a way to make this
> clear?

Probably not, but I don't think that it's worth worrying about. ISTM
that it's inevitable that somebody might get confused whenever we
expose implementation details such as these. This particular example
doesn't seem particularly concerning to me.

Fundamentally, the information that you're showing is a precisely
accurate account of the work performed by VACUUM. If somebody is
bothered by the fact that we're setting VM bits for pages that just
get truncated anyway, then they're bothered by the reality of what
VACUUM does -- and not by the instrumentation itself.

Why not just reuse visibilitymap_count for this (and have it count the
number of all-frozen pages when called by heap_vacuum_rel)? That'll
change the nature of the information shown, but that might actually
make it slightly more useful.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alena Rybakina 2024-10-31 15:18:46 Re: Consider the number of columns in the sort cost model
Previous Message Tom Lane 2024-10-31 15:05:41 Re: make all ereport in gram.y print out relative location