From: | Jeff Ross <jross(at)openvistas(dot)net> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: 15 pg_upgrade with -j |
Date: | 2023-05-23 14:43:54 |
Message-ID: | 79a10835-e830-51f0-bdc1-596807aa5b7a@openvistas.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/22/23 5:43 PM, Adrian Klaver wrote:
>
>>>
>>> From docs:
>>>
>>> https://www.postgresql.org/docs/current/pgupgrade.html
>>>
>>> The --jobs option allows multiple CPU cores to be used for
>>> copying/linking of files and to dump and restore database schemas in
>>> parallel; a good place to start is the maximum of the number of CPU
>>> cores and tablespaces. This option can dramatically reduce the time
>>> to upgrade a multi-database server running on a multiprocessor machine.
>>>
>>> So is the 1400G mostly in one database in the cluster?
>>>
>>>>
>>>> The full commands we are using for pg_upgrade are pretty stock:
>
>> Yes, one big database with about 80 schemas and several other smaller
>> databases so -j should help, right?
>
>
> As I understand it no. That the parallelism is between databases not
> within a database. Further that 'database schemas' refers to schema as
> the overall database object definitions not the namespaces known as
> schemas in the database.
Thanks Adrian. That "restore database schemas in parallel" phrase seems
like it would be really easy to read like we did and expect it to work
with one database and multiple schemas.
Maybe it should be changed to "restore multiple databases in parallel"
instead?
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Andrus | 2023-05-23 14:49:16 | Re: How to speed up product code and subcode match |
Previous Message | Jeff Ross | 2023-05-23 14:38:53 | Re: 15 pg_upgrade with -j |