Re: add timing information to pg_upgrade
Jacob Champion <jchampion@timescale.com>
From: Jacob Champion <jchampion@timescale.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>,
Peter Eisentraut <peter@eisentraut.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-08-01T18:28:27Z
Lists: pgsql-hackers
On Tue, Aug 1, 2023 at 9:00 AM 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-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. +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
Commits
-
pg_upgrade: Bump MESSAGE_WIDTH.
- 2e7d15ab69d9 16.0 landed
- 9625845532ae 17.0 landed