Re: pg_dump schema breakup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump schema breakup
Date
Msg-id 24553.1155932458@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump schema breakup  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_dump schema breakup
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Well, the other issue is how many canned breakup schemes we are going to 
> support. If this particular one is of sufficiently general usefulness 
> then I have no objection. But when you can produce it trivially from the 
> output of "pg_dump -s", the need to hardcode it hardly seems pressing.

FWIW, I am in favor of providing a way to break up the dump output like
this, I was merely objecting to the vocabulary ;-).  We have certainly
seen tons of people burnt by the performance problems inherent in
separate-data-and-schema restores, and splitting the dump into three
parts instead of two seems like it would fix that.

But I also like Alvaro's comment that this should be on the restore side
not so much the dump side.  If you do two or three successive pg_dump
runs to make your dump then you run a nontrivial risk of not getting
consistent dumps.  My advice to people would be to do *one* full
"pg_dump -Fc" and then extract three scripts out of that.

The question then is whether it's worth providing the extraction
functionality in a more canned, user-friendly form than "here, hack up
the -L output with this perl script".  I'd vote yes.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dump schema breakup
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] plpython improvements