Обсуждение: [HACKERS] Vacuum full stats reporting

Поиск
Список
Период
Сортировка

[HACKERS] Vacuum full stats reporting

От
Magnus Hagander
Дата:
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)?

--

Re: [HACKERS] Vacuum full stats reporting

От
Robert Haas
Дата:
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