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
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 |