Re: doc: expand note about pg_upgrade's --jobs option

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: doc: expand note about pg_upgrade's --jobs option
Date: 2025-03-05 15:35:27
Message-ID: Z8hvP82sKppwRmVu@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-03-05 15:44:25 Re: Upgrade FreeBSD CI images to 14.2
Previous Message Tom Lane 2025-03-05 15:28:40 Re: Allow database owners to CREATE EVENT TRIGGER