From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: optimizing pg_upgrade's once-in-each-database steps
Date: Thu, 16 May 2024 20:24:08 -0500
Message-ID: <20240517012408.GA1691322@nathanxps13> (raw)
In-Reply-To: <3b97ab8e295ec3db22baa2dfdd49073449ae1696.camel@j-davis.com>
References: <20240516211638.GA1688936@nathanxps13>
<3b97ab8e295ec3db22baa2dfdd49073449ae1696.camel@j-davis.com>
On Thu, May 16, 2024 at 05:09:55PM -0700, Jeff Davis wrote:
> How much complexity do you avoid by using async instead of multiple
> processes?
If we didn't want to use async, my guess is we'd want to use threads to
avoid complicated IPC. And if we followed pgbench's example for using
threads, it might end up at a comparable level of complexity, although I'd
bet that threading would be the more complex of the two. It's hard to say
definitively without coding it up both ways, which might be worth doing.
> Also, did you consider connecting once to each database and running
> many queries? Most of those seem like just checks.
This was the idea behind 347758b. It may be possible to do more along
these lines. IMO parallelizing will still be useful even if we do combine
more of the steps.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, pgsql@j-davis.com
Subject: Re: optimizing pg_upgrade's once-in-each-database steps
In-Reply-To: <20240517012408.GA1691322@nathanxps13>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox