Re: optimizing pg_upgrade's once-in-each-database steps - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: optimizing pg_upgrade's once-in-each-database steps
Date
Msg-id CADkLM=e0KxKJH0XSG6x2oGK7-W2Eet4AwwCqz5pxAG7QthX4Xw@mail.gmail.com
Whole thread Raw
In response to Re: optimizing pg_upgrade's once-in-each-database steps  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: optimizing pg_upgrade's once-in-each-database steps
List pgsql-hackers
On Tue, Aug 6, 2024 at 3:20 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Sun, Aug 04, 2024 at 07:19:57PM +0100, Ilya Gladyshev wrote:
> -- End of review --

Thanks for the review.  I've attempted to address all your feedback in v8
of the patch set.  I think the names could still use some work, but I
wanted to get the main structure in place before trying to fix them.

I think the underlying mechanism is basically solid, but I have one question: isn't this the ideal case for using libpq pipelining? That would allow subsequent tasks to launch while the main loop slowly gets around to clearing off completed tasks on some other connection.



 

pgsql-hackers by date:

Previous
From: Matthew Kim
Date:
Subject: Re: Remove dependence on integer wrapping
Next
From: Abdoulaye Ba
Date:
Subject: Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size