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
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 |