On Tue, 2 Jan 2024 at 23:03, Kumar, Sachin <sset...@amazon.com> wrote: > > > On 11/12/2023, 01:43, "Tom Lane" <t...@sss.pgh.pa.us > > <mailto:t...@sss.pgh.pa.us>> wrote: > > > I had initially supposed that in a parallel restore we could > > have child workers also commit after every N TOC items, but was > > soon disabused of that idea. After a worker processes a TOC > > item, any dependent items (such as index builds) might get > > dispatched to some other worker, which had better be able to > > see the results of the first worker's step. So at least in > > this implementation, we disable the multi-command-per-COMMIT > > behavior during the parallel part of the restore. 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. IMHO most of the customer will have > single large > database, and not using parallel restore will cause slow pg_upgrade. > > 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.
CFBot shows that the patch does not apply anymore as in [1]: === Applying patches on top of PostgreSQL commit ID 46a0cd4cefb4d9b462d8cc4df5e7ecdd190bea92 === === applying patch ./v9-005-parallel_pg_restore.patch patching file src/bin/pg_upgrade/pg_upgrade.c Hunk #3 FAILED at 650. 1 out of 3 hunks FAILED -- saving rejects to file src/bin/pg_upgrade/pg_upgrade.c.rej Please post an updated version for the same. [1] - http://cfbot.cputube.org/patch_46_4713.log Regards, Vignesh
