Feedback-ID: ie0a040ee:Fastmail
Message-ID: <4fe4c4d2-e87d-fd6d-0866-a453a2d4c32a@eisentraut.org>
Date: Wed, 2 Aug 2023 09:14:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.13.0
Subject: Re: add timing information to pg_upgrade
Content-Language: en-US
To: Nathan Bossart <nathandbossart@gmail.com>,
 Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: <20230727235134.GA3658499@nathanxps13>
 <204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org>
 <AD7ABA5E-E024-46C4-A691-E51E4BFE9A15@yesql.se>
 <20230801160006.GB723589@nathanxps13>
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <20230801160006.GB723589@nathanxps13>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/4fe4c4d2-e87d-fd6d-0866-a453a2d4c32a%40eisentraut.org>
Precedence: bulk

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?