Re: add timing information to pg_upgrade
От | Jacob Champion |
---|---|
Тема | Re: add timing information to pg_upgrade |
Дата | |
Msg-id | CAAWbhmih90zLbwDkFoGz_bCMuPnmpvskjARBRXuUXJkxOZ04NQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: add timing information to pg_upgrade (Nathan Bossart <nathandbossart@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: