From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: add timing information to pg_upgrade |
Date: | 2023-08-01 07:45:09 |
Message-ID: | 204e3982-78be-7550-fdb3-063ecd368f1f@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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).
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-08-01 07:46:02 | Re: add timing information to pg_upgrade |
Previous Message | Kyotaro Horiguchi | 2023-08-01 06:59:12 | Re: Incorrect handling of OOM in WAL replay leading to data loss |