Re: doc: expand note about pg_upgrade's --jobs option
| От | Nathan Bossart |
|---|---|
| Тема | Re: doc: expand note about pg_upgrade's --jobs option |
| Дата | |
| Msg-id | Z8h7wjNJmngqHhK9@nathan обсуждение исходный текст |
| Ответ на | Re: doc: expand note about pg_upgrade's --jobs option (Nathan Bossart <nathandbossart@gmail.com>) |
| Ответы |
Re: doc: expand note about pg_upgrade's --jobs option
|
| Список | pgsql-hackers |
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. -- nathan
Вложения
В списке pgsql-hackers по дате отправления: