Report runtimes in pg_upgrade verbose mode
When doing performance hacking on pg_upgrade it's often important to see
individual runtimes to isolate changes. I've written versions of the attached
patch numerous times, and I wouldn't be surprised if others have done the same.
Is there any interest in adding something like the attached to pg_upgrade? The
patch needs some cleaning and tidying up but I wanted to to gauge interest
before investing time. I've added it to verbose mode mainly since it's not
really all that informative for regular users I think.
--
Daniel Gustafsson
Attachments:
0001-Report-runtime-for-steps-in-pg_upgrade-verbose-mode.patchapplication/octet-stream; name=0001-Report-runtime-for-steps-in-pg_upgrade-verbose-mode.patch; x-unix-mode=0644Download+40-2
On Wed, Jun 19, 2024 at 04:50:59PM +0200, Daniel Gustafsson wrote:
When doing performance hacking on pg_upgrade it's often important to see
individual runtimes to isolate changes. I've written versions of the attached
patch numerous times, and I wouldn't be surprised if others have done the same.
Indeed: /messages/by-id/flat/20230727235134.GA3658499@nathanxps13
Is there any interest in adding something like the attached to pg_upgrade? The
patch needs some cleaning and tidying up but I wanted to to gauge interest
before investing time. I've added it to verbose mode mainly since it's not
really all that informative for regular users I think.
I've been using 'ts -i' as Peter suggested [0]/messages/by-id/32d24bcf-9ac4-b10e-4aa2-da6975312eb2@eisentraut.org, and that has worked
decently well. One other thing that I've noticed is that some potentially
long-running tasks don't have corresponding reports. For example, the
initial get_db_rel_and_slot_infos() on the old cluster doesn't report
anything, but that is often one of the most time-consuming steps.
[0]: /messages/by-id/32d24bcf-9ac4-b10e-4aa2-da6975312eb2@eisentraut.org
--
nathan