On Thu, Oct 31, 2024 at 11:15 AM Peter Geoghegan <p...@bowt.ie> wrote: > > On Thu, Oct 31, 2024 at 10:22 AM Melanie Plageman > <melanieplage...@gmail.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.
Makes sense to me. Though, I'm looking at it as a developer. > 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. I'm biased because I want the count of pages newly set all-frozen in the VM for another patch. You think exposing the total number of all-frozen pages at the end of the vacuum is more useful to users? - Melanie
