> 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
