MIME-Version: 1.0
References: <20230727235134.GA3658499@nathanxps13> <204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org>
 <AD7ABA5E-E024-46C4-A691-E51E4BFE9A15@yesql.se> <20230801160006.GB723589@nathanxps13>
In-Reply-To: <20230801160006.GB723589@nathanxps13>
From: Jacob Champion <jchampion@timescale.com>
Date: Tue, 1 Aug 2023 11:28:27 -0700
Message-ID: <CAAWbhmih90zLbwDkFoGz_bCMuPnmpvskjARBRXuUXJkxOZ04NQ@mail.gmail.com>
Subject: Re: add timing information to pg_upgrade
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Peter Eisentraut <peter@eisentraut.org>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAAWbhmih90zLbwDkFoGz_bCMuPnmpvskjARBRXuUXJkxOZ04NQ%40mail.gmail.com>
Precedence: bulk

On Tue, Aug 1, 2023 at 9:00=E2=80=AFAM Nathan Bossart <nathandbossart@gmail=
.com> wrote:
> >> On 1 Aug 2023, at 09:45, Peter Eisentraut <peter@eisentraut.org> wrote=
:
> >> But who would use that, other than, you know, you, right now?

/me raises hand

Or at least, me back when I was hacking on pg_upgrade performance.
This, or something like it, would have been fantastic.

> >> I think the pg_upgrade output is already too full with not-really-acti=
onable information (like most of the above "Checking ..." are not really in=
teresting 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.

+1. One of our findings at $prevjob was that some users *really* want
some indication, anything at all, that things are progressing and
aren't stuck. There was a lot of anxiety around upgrades.

(There are probably _better_ ways to indicate progress than the
current step divisions... But even poor progress indicators seemed to
lower blood pressures, IIRC.)

> 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.

I agree that millisecond-level timing should probably be opt-in.

--Jacob