Re: pg_dump test instability
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-08-27T14:45:58Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> However, at least for the directory-format case (which I think is the >> only one supported for parallel restore), we could make it compare the >> file sizes of the TABLE DATA items. That'd work pretty well as a proxy >> for both the amount of effort needed for table restore, and the amount >> of effort needed to build indexes on the tables afterwards. > Parallel restore also works w/ custom-format dumps. Really. Well then the existing code is even more broken, because it only does this sorting for directory output: /* If we do a parallel dump, we want the largest tables to go first */ if (archiveFormat == archDirectory && numWorkers > 1) sortDataAndIndexObjectsBySize(dobjs, numObjs); so that parallel restore is completely left in the lurch with a custom-format dump. But I imagine we can get some measure of table data size out of a custom dump too. regards, tom lane
Commits
-
Improve parallel scheduling logic in pg_dump/pg_restore.
- 548e50976ce7 12.0 landed