Re: POC: track vacuum/analyze cumulative time per relation

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: track vacuum/analyze cumulative time per relation
Date: 2025-01-27 17:22:16
Message-ID: CAA5RZ0vpAA+jXiCjjO5DGbLTUVmqe99ioCx0dkg1FKNc1h2biA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I think that this is hiding a behavior change while adding new
> counters, and both changes are independent.

That's a fair point.

> Another thing that is
> slightly incorrect to do if we take the argument of only adding the
> counters is moving around the call of pgstat_progress_end_command(),
> because it's not really wrong as-is, either. I'd suggest to make all
> that a separate discussion.

Yeah, we have inconsistency between when vacuum and analyze
command ends as well as inconsistency between the time
reported to pg_stats vs the logs. I will start a follow-up thread for
this.

> I have put my hands on this patch, and at the end I think that we
> should just do the attached, which is simpler and addresses your
> use-case. Note also that the end time is acquired while the entries
> are not locked in the report routines, and some tweaks in the docs and
> comments.

Thanks for the update. This LGTM.

Regards,

Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-01-27 17:30:51 Re: Skip collecting decoded changes of already-aborted transactions
Previous Message Robert Haas 2025-01-27 17:03:53 Re: Eagerly scan all-visible pages to amortize aggressive vacuum