Re: optimizing pg_upgrade's once-in-each-database steps
От | Nathan Bossart |
---|---|
Тема | Re: optimizing pg_upgrade's once-in-each-database steps |
Дата | |
Msg-id | ZoMK9ZhOsWEKqxlM@nathan обсуждение исходный текст |
Ответ на | Re: optimizing pg_upgrade's once-in-each-database steps (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: optimizing pg_upgrade's once-in-each-database steps
|
Список | pgsql-hackers |
On Mon, Jul 01, 2024 at 03:58:16PM -0400, Robert Haas wrote: > On Mon, Jul 1, 2024 at 3:47 PM Nathan Bossart <nathandbossart@gmail.com> wrote: >> 0001 introduces a new API for registering callbacks and running them in >> parallel on all databases in the cluster. This new system manages a set of >> "slots" that follow a simple state machine to asynchronously establish a >> connection and run the queries. It uses system() to wait for these >> asynchronous tasks to complete. Users of this API only need to provide two >> callbacks: one to return the query that should be run on each database and >> another to process the results of that query. If multiple queries are >> required for each database, users can provide multiple sets of callbacks. > > I do really like the idea of using asynchronous communication here. It > should be significantly cheaper than using multiple processes or > threads, and maybe less code, too. But I'm confused about why you > would need or want to use system() to wait for asynchronous tasks to > complete. Wouldn't it be something like select()? Whoops, I meant to type "select()" there. Sorry for the confusion. -- nathan
В списке pgsql-hackers по дате отправления: