Re: pg_dump additional options for performance
От | Tom Lane |
---|---|
Тема | Re: pg_dump additional options for performance |
Дата | |
Msg-id | 24456.1217094974@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump additional options for performance (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: pg_dump additional options for performance
Re: pg_dump additional options for performance Re: pg_dump additional options for performance |
Список | pgsql-patches |
Simon Riggs <simon@2ndquadrant.com> writes: > I want to dump tables separately for performance reasons. There are > documented tests showing 100% gains using this method. There is no gain > adding this to pg_restore. There is a gain to be had - parallelising > index creation, but this patch doesn't provide parallelisation. Right, but the parallelization is going to happen sometime, and it is going to happen in the context of pg_restore. So I think it's pretty silly to argue that no one will ever want this feature to work in pg_restore. To extend the example I just gave to Stephen, I think a fairly probable scenario is where you only need to tweak some "before" object definitions, and then you could do pg_restore --schema-before-data whole.dump >before.sql edit before.sql psql -f before.sql target_db pg_restore --data-only --schema-after-data -d target_db whole.dump which (given a parallelizing pg_restore) would do all the time-consuming steps in a fully parallelized fashion. regards, tom lane
В списке pgsql-patches по дате отправления: