On Thu, Jun 30, 2022 at 8:43 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Ah, I missed that. I think that in the test case I was using, there
> was a conflicting pin but there were no dead tuples, so that line
> wasn't present in the output.
Even if there was a DEAD tuple, your test would still have to account
for opportunistic pruning before the cursor acquires its blocking pin
(I'm guessing that you're using a cursor for this). The earlier
pruning could turn the DEAD tuple into either an LP_UNUSED item (in
the case of a heap-only tuple) or an LP_DEAD stub line pointer.
As I said, any existing LP_DEAD items will get put in the dead_items
array by lazy_scan_noprune, very much like it would in the
cleanup-lock-acquired/lazy_scan_prune case.
> Maybe nothing. I just thought you'd completely removed all reporting
> on this, and I'm glad that's not so.
The important idea behind all this is that VACUUM now uses a slightly
more abstract definition of scanned_pages. This is far easier to work
with at a high level, especially in the instrumentation code used by
VACUUM VERBOSE.
You may have also noticed that VACUUM VERBOSE/autovacuum logging
actually shows the number of scanned pages in Postgres 15, for the
first time -- even though that's very basic information. The revised
definition of scanned_pages enabled that enhancement. We are no longer
encumbered by the existence of a no-cleanup-lock-page special case.
--
Peter Geoghegan
