Re: Vacuum timing in pg_stat_all_tables - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Vacuum timing in pg_stat_all_tables
Date
Msg-id Z8cbKlDUg7zYMv8J@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Vacuum timing in pg_stat_all_tables  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Mar 04, 2025 at 08:54:13AM -0600, Nathan Bossart wrote:
> On Tue, Mar 04, 2025 at 03:12:18PM +0100, Magnus Hagander wrote:
> > In light of bb8dff9995f (add cost delay time to progress views), looking at
> > the output of 30a6ed0ce4b (track per-relation time spent on vacuum and
> > analyze), it struck me as a bit unclear of what the time is really showing.
> > 
> > Do we want to do something similar for the table views? Or if not, we
> > should probably at least document the effect of cost based vacuum delay on
> > those timings - as in if they are including it or not (which I do believe
> > they are).
> 
> I could see it being useful to have the total cost delay time in those
> views.  The information in the progress views goes away when vacuuming is
> done, while the table views would retain it indefinitely.

+1, I think that could be useful to "retain" this information on a per-table
basis.

> > While more stats are always nice :), I think just being clear about it in
> > the docs would perhaps be enough for now? Maybe just appending something
> > along the line of "(including cost based delaying)"?

Like "more stats are always nice" I think that "more explanations in the doc" are
always nice, so I don't see any reason why not to add this extra explanation.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: what's going on with lapwing?
Next
From: Andrei Lepikhov
Date:
Subject: Re: making EXPLAIN extensible