Re: [HACKERS] Vacuum full stats reporting - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Vacuum full stats reporting
Date
Msg-id CA+TgmoZWM_+rBSd824Zbx7yWiAWXu8L2STYv=m70ZQb4hQC_sA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Vacuum full stats reporting  (Magnus Hagander <magnus@hagander.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] TAP tests take a long time