Re: add vacuum starttime columns

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, nickyang <nickyang905(at)gmail(dot)com>
Subject: Re: add vacuum starttime columns
Date: 2024-12-31 17:41:14
Message-ID: CAA5RZ0u8xmoGMU173EzKaL0Gi08oTmLG4h-0u3jAt6575cMATw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2024-12-31 18:22:14 Strange issue with NFS mounted PGDATA on ugreen NAS
Previous Message Roberto C. Sánchez 2024-12-31 17:14:37 Re: Backport of CVE-2024-10978 fix to older pgsql versions (11, 9.6, and 9.4)