Thread: [HACKERS] Vacuum full stats reporting
Right now, VACUUM FULL are not reported in pgstat. That seems bad:ish. I can see two reasonable ways to proceed:
1. Start reporting VACUUM FULL as regular vacuums, so they count up vacuum_count and last_vacuum in pg_stat_*_tables.
2. Create a new set of counters for CLUSTER and VACUUM FULL (which are arguably the same in this regard, in how they behave wrt the system), and add counters cluster_count and last_cluster in pg_stat_*_tables.
Option 2 clearly adds more information and I can see quite a few cases where this would be useful. But what do people think of the potential overhead there? Worth it?
--
Due to this, it also does not (AFAICT) reset the counters for things like dead tuples. This part seems like a pure bug. Perhaps we should at least do something like (1) as a backpatch, even if we decide to do (2) in future versions (11+ i guess)?
On Mon, Apr 10, 2017 at 4:36 AM, Magnus Hagander <magnus@hagander.net> wrote: > Right now, VACUUM FULL are not reported in pgstat. That seems bad:ish. I can > see two reasonable ways to proceed: > > 1. Start reporting VACUUM FULL as regular vacuums, so they count up > vacuum_count and last_vacuum in pg_stat_*_tables. > > 2. Create a new set of counters for CLUSTER and VACUUM FULL (which are > arguably the same in this regard, in how they behave wrt the system), and > add counters cluster_count and last_cluster in pg_stat_*_tables. > > Option 2 clearly adds more information and I can see quite a few cases where > this would be useful. But what do people think of the potential overhead > there? Worth it? > > Due to this, it also does not (AFAICT) reset the counters for things like > dead tuples. This part seems like a pure bug. Perhaps we should at least do > something like (1) as a backpatch, even if we decide to do (2) in future > versions (11+ i guess)? Maybe we should have done #1 originally, but I think it's too late to back-patch a behavior change. We don't really want the behavior in this area to be different depending on which minor release somebody is running, or at least I don't. I think it's better to wait and deal with this in v11 in whatever way we think is best. I'd favor #2 unless the overhead is unacceptable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company