From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: add timing information to pg_upgrade |
Date: | 2023-08-02 15:59:15 |
Message-ID: | 20230802155915.GA1008426@nathanxps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 02, 2023 at 09:14:06AM +0200, Peter Eisentraut wrote:
> 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?
Sure, we could just leave it at that unless anyone sees a reason to bake it
in.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-08-02 16:04:10 | Re: PATCH: Using BRIN indexes for sorted output |
Previous Message | Alena Rybakina | 2023-08-02 15:58:37 | Re: POC, WIP: OR-clause support for indexes |