Re: add timing information to pg_upgrade

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: add timing information to pg_upgrade
Дата
Msg-id 204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org
обсуждение исходный текст
Ответ на add timing information to pg_upgrade  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: add timing information to pg_upgrade  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
On 28.07.23 01:51, Nathan Bossart wrote:
> I've been looking into some options for reducing the amount of downtime
> required for pg_upgrade, and $SUBJECT seemed like something that would be
> worthwhile independent of that effort.  The attached work-in-progress patch
> adds the elapsed time spent in each step, which looks like this:
> 
>    Performing Consistency Checks
>    -----------------------------
>    Checking cluster versions                                   ok (took 0 ms)
>    Checking database user is the install user                  ok (took 3 ms)
>    Checking database connection settings                       ok (took 4 ms)
>    Checking for prepared transactions                          ok (took 2 ms)
>    Checking for system-defined composite types in user tables  ok (took 82 ms)
>    Checking for reg* data types in user tables                 ok (took 55 ms)
>    ...
> 
> 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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Incorrect handling of OOM in WAL replay leading to data loss
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: add timing information to pg_upgrade