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  (daveg <daveg@sonic.net>)
Re: pg_dump additional options for performance  (Simon Riggs <simon@2ndquadrant.com>)
Re: pg_dump additional options for performance  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump additional options for performance
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: pg_dump additional options for performance