On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote:
>> On 1 Aug 2023, at 09:45, Peter Eisentraut <peter@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