Re: add timing information to pg_upgrade

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add timing information to pg_upgrade
Date: 2023-08-02 08:30:00
Message-ID: CALj2ACVn0DU_xJ+i1GmpSw+QcX-n2JcHG_1M-R7omimwqqyN+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 2, 2023 at 12:44 PM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 01.08.23 18:00, Nathan Bossart wrote:
> > One of the main purposes of this thread is to gauge interest. I'm hoping
> > there are other developers who are interested in reducing
> > pg_upgrade-related downtime, and it seemed like it'd be nice to have
> > built-in functionality for measuring the step times instead of requiring
> > folks to apply this patch every time. And I think users might also be
> > interested in this information, if for no other reason than to help us
> > pinpoint which steps are taking longer for various workloads.
>
> If it's just for developers and expert users, perhaps existing
> shell-level functionality like "pg_upgrade | ts" would suffice?

Interesting. I had to install moreutils package to get ts. And,
something like ts command may or may not be available on all
platforms. Moreover, the ts command gives me the timestamps for each
of the messages printed, so an extra step is required to calculate the
time taken for an operation. I think it'd be better if pg_upgrade can
calculate the time taken for each operation, and I'm okay if it is an
opt-in feature with --verbose option.

[1]
Aug 02 07:44:17 Sync data directory to disk ok
Aug 02 07:44:17 Creating script to delete old cluster ok
Aug 02 07:44:17 Checking for extension updates ok

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-08-02 09:01:39 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Previous Message Peter Eisentraut 2023-08-02 08:29:39 Re: cataloguing NOT NULL constraints