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
|
Список | 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 по дате отправления: