On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote: >> On 1 Aug 2023, at 09:45, Peter Eisentraut <pe...@eisentraut.org> wrote: >> On 28.07.23 01:51, Nathan Bossart wrote: > >>> This information can be used to better understand where the time is going >>> and to validate future improvements. >> >> But who would use that, other than, you know, you, right now?
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. >> I think the pg_upgrade output is already too full with not-really-actionable >> information (like most of the above "Checking ..." are not really >> interesting for a regular user). Perhaps. But IMO it's nice to know that it's doing things and making progress, even if you don't understand exactly what it's doing all the time. That being said, I wouldn't be opposed to hiding some of this output behind a --verbose or --debug option or consolidating some of the steps into fewer status messages. > Maybe if made opt-in with a --debug option, or even a compiler option for > enabling only in specialized debugging builds? I'm totally okay with making the timing information an opt-in feature. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
