From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: 15 pg_upgrade with -j |
Date: | 2023-05-23 02:10:48 |
Message-ID: | a3b25cac-1f54-99c8-1bf4-91ade7d94e4d@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/22/23 18:42, Tom Lane wrote:
> Jeff Ross <jross(at)openvistas(dot)net> writes:
>> On 5/22/23 5:24 PM, Adrian Klaver wrote:
>>> So is the 1400G mostly in one database in the cluster?
>>>
>> Yes, one big database with about 80 schemas and several other smaller
>> databases so -j should help, right?
> AFAICT from a quick look at the code, you won't get any meaningful
> parallelism unless you have several large DBs and/or several large
> tablespaces.
Hmm. I'm glad I'm reading this now.
> It looks like the assumption was that issuing link()
> requests in parallel wouldn't help much but just swamp your disk
> if they're all on the same filesystem.
> Maybe that could use rethinking, not sure.
It does need rethinking in the era of VMs and SANs. /var/lib/pgsql/15 is
going to be on a different LUN from /var/lib/pgsql/9.6 just like
/var/lib/pgsql/backups is on a different LUN.
--
Born in Arizona, moved to Babylonia.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrus | 2023-05-23 06:53:02 | How to speed up product code and subcode match |
Previous Message | Tatsuo Ishii | 2023-05-23 00:57:24 | Re: PGCon remote attendance |