Date: Wed, 2 Aug 2023 08:59:15 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Daniel Gustafsson <daniel@yesql.se>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: add timing information to pg_upgrade
Message-ID: <20230802155915.GA1008426@nathanxps13>
References: <20230727235134.GA3658499@nathanxps13>
 <204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org>
 <AD7ABA5E-E024-46C4-A691-E51E4BFE9A15@yesql.se>
 <20230801160006.GB723589@nathanxps13>
 <4fe4c4d2-e87d-fd6d-0866-a453a2d4c32a@eisentraut.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4fe4c4d2-e87d-fd6d-0866-a453a2d4c32a@eisentraut.org>
Archived-At: 
 <https://www.postgresql.org/message-id/20230802155915.GA1008426%40nathanxps13>
Precedence: bulk

On Wed, Aug 02, 2023 at 09:14:06AM +0200, Peter Eisentraut 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?

Sure, we could just leave it at that unless anyone sees a reason to bake it
in.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com