Re: [HACKERS] Vacuum full stats reporting

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Vacuum full stats reporting
Дата
Msg-id CA+TgmoZWM_+rBSd824Zbx7yWiAWXu8L2STYv=m70ZQb4hQC_sA@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Vacuum full stats reporting  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] TAP tests take a long time