> "Tom Lane" <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote:
> FWIW, I agree with Jacob's concern about it being a bad idea to let > users of pg_upgrade pass down arbitrary options to pg_dump/pg_restore. > I think we'd regret going there, because it'd hugely expand the set > of cases pg_upgrade has to deal with. > Also, pg_upgrade is often invoked indirectly via scripts, so I do > not especially buy the idea that we're going to get useful control > input from some human somewhere. I think we'd be better off to > assume that pg_upgrade is on its own to manage the process, so that > if we need to switch strategies based on object count or whatever, > we should put in a heuristic to choose the strategy automatically. > It might not be perfect, but that will give better results for the > pretty large fraction of users who are not going to mess with > weird little switches. I have updated the patch to use heuristic, During pg_upgrade we count Large objects per database. During pg_restore execution if db large_objects count is greater than LARGE_OBJECTS_THRESOLD (1k) we will use --restore-blob-batch-size. I also modified pg_upgrade --jobs behavior if we have large_objects (> LARGE_OBJECTS_THRESOLD) + /* Restore all the dbs where LARGE_OBJECTS_THRESOLD is not breached */ + restore_dbs(stats, true); + /* reap all children */ + while (reap_child(true) == true) + ; + /* Restore rest of the dbs one by one with pg_restore --jobs = user_opts.jobs */ + restore_dbs(stats, false); /* reap all children */ while (reap_child(true) == true) ; Regards Sachin
pg_upgrade_improvements_v7.diff
Description: pg_upgrade_improvements_v7.diff