Re: pg_dump additional options for performance - Mailing list pgsql-patches

From Tom Lane
Subject Re: pg_dump additional options for performance
Date
Msg-id 24456.1217094974@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump additional options for performance  (Simon Riggs <simon@2ndquadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump additional options for performance
Next
From: "Joshua D. Drake"
Date:
Subject: Re: pg_dump additional options for performance