| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: add timing information to pg_upgrade |
| Date: | 2023-08-02 07:14:06 |
| Message-ID: | 4fe4c4d2-e87d-fd6d-0866-a453a2d4c32a@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01.08.23 18:00, Nathan Bossart wrote:
> One of the main purposes of this thread is to gauge interest. I'm hoping
> there are other developers who are interested in reducing
> pg_upgrade-related downtime, and it seemed like it'd be nice to have
> built-in functionality for measuring the step times instead of requiring
> folks to apply this patch every time. And I think users might also be
> interested in this information, if for no other reason than to help us
> pinpoint which steps are taking longer for various workloads.
If it's just for developers and expert users, perhaps existing
shell-level functionality like "pg_upgrade | ts" would suffice?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2023-08-02 07:15:27 | Re: add timing information to pg_upgrade |
| Previous Message | Peter Smith | 2023-08-02 06:43:33 | Re: Adding a LogicalRepWorker type field |