Unifying VACUUM VERBOSE and log_autovacuum_min_duration output

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Unifying VACUUM VERBOSE and log_autovacuum_min_duration output
Date: 2021-11-26 20:37:32
Message-ID: CAH2-WzmW4Me7_qR4X4ka7pxP-jGmn7=Npma_-Z-9Y1eD0MQRLw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I think that it's worth unifying VACUUM VERBOSE and
log_autovacuum_min_duration output, to remove the redundancy, and to
provide more useful VACUUM VERBOSE output.

Both variants already output approximately the same things. But, each
variant reports on certain details that the other variant lacks. I
find the extra information provided by log_autovacuum_min_duration far
more useful than the extra details provided by VACUUM VERBOSE. This is
probably because we've focussed on improving the former over the
latter, probably because autovacuum is much more interesting than
VACUUM on average, in practice, to users.

Unifying everything cannot be approached mechanically, so doing this
requires real buy-in. It's a bit tricky because VACUUM VERBOSE is
supposed to show real time information about what just finished, as a
kind of rudimentary progress indicator, while log_autovacuum_*
summarizes the whole entire VACUUM operation. This difference is most
notable when there are multiple index vacuuming passes ("index
scans"), or when we truncate the heap relation.

My preferred approach to this is simple: redefine VACUUM VERBOSE to
not show incremental output, which seems rather unhelpful anyway. This
does mean that VACUUM VERBOSE won't show certain information that
might occasionally be useful to hackers. For example, there is
detailed information about how rel truncation happened in the VERBOSE
output, and detailed information about how many index tuples were
deleted by each round of index vacuuming, for each individual index.
We can keep this extra information as DEBUG2 messages, as in the
current !VERBOSE case (or perhaps make some of them DEBUG1). I don't
think that we need to keep the getrusage() stuff at all, though.

I think that this would significantly improve VACUUM VERBOSE output,
especially for users, but also for hackers. Here are my reasons, in
detail:

* We have pg_stat_progress_vacuum these days.

* VACUUM VERBOSE doesn't provide much of the most useful
instrumentation that we have available in log_autovacuum_min_duration,
and yet produces output that is ludicrously, unmanageably verbose --
lots of pg_rusage_show() information for each and every step, which
just isn't useful.

* I really miss the extra stuff that log_autovacuum_min_duration
provides when I run VACUUM VERBOSE, though.

* In practice having multiple rounds of index vacuuming is quite rare
these days. And when it does happen it's interesting because it
happened at all -- I don't really care about the breakdown beyond
that. If I ever do care about the very fine details, I can easily set
client_min_messages to DEBUG2 on that one occasion.

* The fact that VACUUM VERBOSE will no longer report on
IndexBulkDeleteResult.num_index_tuples and
IndexBulkDeleteResult.tuples_removed seems like no great loss to me --
the fact that the number might be higher or lower for an index
typically means very little these days, with the improvements made to
index tuple deletion.

VERBOSE will still report on IndexBulkDeleteResult.pages_*, which is
what really matters. VERBOSE will also report on LP_DEAD-in-heap items
removed (or not removed) directly, which is a generic upper bound on
tuples_removed, that applies to all indexes.

* The detailed lazy_truncate_heap() instrumentation output by VACUUM
VERBOSE just isn't useful outside of debugging scenarios -- it just
isn't actionable to users (users only really care about how much
smaller the table became through truncation). The low level details
could easily be output as DEBUG1 (not DEBUG2) instead.

Thoughts?
--
Peter Geoghegan

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-11-26 21:16:33 Re: WIP: WAL prefetch (another approach)
Previous Message Daniel Gustafsson 2021-11-26 20:14:05 Re: Windows build warnings