Re: doc: expand note about pg_upgrade's --jobs option - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: doc: expand note about pg_upgrade's --jobs option
Date
Msg-id CABUevEypumDBOSebnVdgatLs8Rbr55GBCPYSA8mSXu13F0JNrg@mail.gmail.com
Whole thread Raw
In response to Re: doc: expand note about pg_upgrade's --jobs option  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers

On Wed, Mar 5, 2025 at 5:28 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Wed, Mar 05, 2025 at 09:35:27AM -0600, Nathan Bossart wrote:
> On Wed, Mar 05, 2025 at 01:52:40PM +0100, Magnus Hagander wrote:
>> Another option that I think would also work is to just cut down the details
>> to just "The <option>--jobs</option> option allows multiple CPU cores to be
>> used".
>
> That's fine with me.  It's probably not particularly actionable
> information, anyway.  If anything, IMHO we should make it clear to users
> that the parallelization is per-database (except for file transfer, which
> is per-tablespace).  If you've just got one big database in the default
> tablespace, --jobs won't help.
>
>> I think this is also slightly confusing, but maybe that's a
>> non-native-english thing: "a good place to start is the maximum of the
>> number of  CPU cores and tablespaces.". Am I supposed to set it to
>> max(cpucores, ntablespaces) or to max(cpucores+ntablespaces)?
>
> I've always read it to mean the former.  But I'm not sure that's great
> advice.  If you have 8 cores and 100 tablespaces, does it make sense to use
> --jobs=100?  Ordinarily, I'd suggest the number of cores as the starting
> point.

Here's another attempt at the patch based on the latest discussion.

LGTM! 

--

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Nikhil Kumar Veldanda
Date:
Subject: Re: ZStandard (with dictionaries) compression support for TOAST compression