Re: pg_dump test instability
От | Tom Lane |
---|---|
Тема | Re: pg_dump test instability |
Дата | |
Msg-id | 1665.1535381158@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump test instability (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: pg_dump test instability
|
Список | 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
В списке pgsql-hackers по дате отправления: