Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times
В списке pgsql-admin по дате отправления:
| От | Jan Lentfer |
|---|---|
| Тема | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times |
| Дата | |
| Msg-id | 7dc008d2afe5d9b9dcfd90a3bb540f98@imap.lan.net обсуждение |
| Ответ на | Re: pg_dump and pg_restore with multiple streams does Not seem to improve overall times (Mel Llaguno <mllaguno@coverity.com>) |
| Ответы |
Re: pg_dump and pg_restore with multiple streams does Not
seem to improve overall times
|
| Список | pgsql-admin |
Am 2015-05-04 18:19, schrieb Mel Llaguno: > My understanding of parallel dump performance is that it only makes a > difference when you have a large number of DBs (thousands if not tens > of > thousands). We performed similar testing using 9.3.x and found little > performance gains using -j (with 100+ tables). See Bruce Momjian’s > post : > http://momjian.us/main/blogs/pgblog/2012.html I don't know about parallel pg_dump as we use -Fc and pg_dump can't do that in parallel (afaik). For dumping I have wrapped pg_dump in a shell script to dump several databases in parallel. But for pg_restore -j option does make a big difference, at least when you have a lot of larger tables and indexes. Regards, Jan
В списке pgsql-admin по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера