public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Kumar, Sachin <[email protected]>
Cc: Robins Tharakan <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: Jan Wieck <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Zhihong Yu <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: pg_upgrade failing for 200+ million Large Objects
Date: Tue, 02 Jan 2024 13:06:18 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<20220825003227.GA1456581@nathanxps13>
<[email protected]>
<20220908231807.GA2242918@nathanxps13>
<CAAWbhmgUb8p7ff_ZX5jCvqM=ipPxbbDJTXMNVzH-Ho_CXVkRHA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
"Kumar, Sachin" <[email protected]> writes:
>> On 11/12/2023, 01:43, "Tom Lane" <[email protected] <mailto:[email protected]>> wrote:
>> ... Maybe that
>> could be improved in future, but it seems like it'd add a
>> lot more complexity, and it wouldn't make life any better for
>> pg_upgrade (which doesn't use parallel pg_restore, and seems
>> unlikely to want to in future).
> I was not able to find email thread which details why we are not using
> parallel pg_restore for pg_upgrade.
Well, it's pretty obvious isn't it? The parallelism is being applied
at the per-database level instead.
> IMHO most of the customer will have single large
> database, and not using parallel restore will cause slow pg_upgrade.
You've offered no justification for that opinion ...
> I am attaching a patch which enables parallel pg_restore for DATA and POST-DATA part
> of dump. It will push down --jobs value to pg_restore and will restore
> database sequentially.
I don't think I trust this patch one bit. It makes way too many
assumptions about how the --section options work, or even that they
will work at all in a binary-upgrade situation. I've spent enough
time with that code to know that --section is pretty close to being
a fiction. One point in particular is that this would change the
order of ACL restore relative to other steps, which almost certainly
will cause problems for somebody.
regards, tom lane
view thread (18+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_upgrade failing for 200+ million Large Objects
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox