On Wed, Apr 17, 2019 at 5:00 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: > > I'm thinking that we really need to upgrade vacuum's reporting totals > > so that it accounts in some more-honest way for pre-existing dead > > line pointers. The patch as it stands has made the reporting even more > > confusing, rather than less so. > > Here's a couple of ideas about that: > > 1. Ignore heap_page_prune's activity altogether, on the grounds that > it's just random chance that any cleanup done there was done during > VACUUM and not some preceding DML operation. Make tups_vacuumed > be the count of dead line pointers removed. The advantage of this > way is that tups_vacuumed would become independent of previous > non-VACUUM pruning activity, as well as preceding index-cleanup-disabled > VACUUMs. But maybe it's hiding too much information. > > 2. Have heap_page_prune count, and add to tups_vacuumed, only HOT > tuples that it deleted entirely. The action of replacing a DEAD > root tuple with a dead line pointer doesn't count for anything. > Then also add the count of dead line pointers removed to tups_vacuumed. > > Approach #2 is closer to the way we've defined tups_vacuumed up to > now, but I think it'd be more realistic in cases where previous > pruning or index-cleanup-disabled vacuums have left lots of dead > line pointers.
On top of the approach #2, how about reporting the number of line pointers we left so that user can notice that there are many dead line pointers in the table? > > I'm not especially wedded to either of these --- any other ideas? Or, how about reporting the vacuumed tuples and line pointers we separately? It might be too detailed but since with this patch we delete either only tuples or only line pointers, it's more accurate. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
