> Also, the log files give you historical overview that the pg_stat views simply cannot provide,
> in addition to the actual details of what was vacuumed and why.
Logfiles have the ability to provide more details and they have their place.
However, one must also think about how much logging they want to
enable and this limits how much they can learn about the system.
A user also needs to come up with a custom solution to parse and process
data.
This is why we provide other (auto)vacuum/(auto)analyze metrics in pg_stat
views. logs alone are not very practical to learn about such an important
activity in the cluster.
Being able to quickly answer "how long are vacuum/autovacuums are
taking per table?"
and being able to trend this information without enabling additional logging
is a good user experience in my mind.
> For what it's worth, log_autovacuum_min_duration is one of the few parameters that I always
> recommend be turned on at the highest level (i.e. log it all). The extra log verbosity is well worth it.
If we can avoid this additional logging, the better IMO.
I would like to see us actually expose more vacuum level metrics in
pg_stats, so maybe
this is the time to think about potentially dedicated views for vacuum/analyze.
Regards,
Sami
