From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Naz Gassiep <naz(at)mira(dot)net>, Andreas Joseph Krogh <andreak(at)officenet(dot)no>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_dump schema breakup |
Date: | 2006-08-18 20:20:58 |
Message-ID: | 24553.1155932458@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-08-18 20:27:23 | Re: [PATCHES] plpython improvements |
Previous Message | Andrew Dunstan | 2006-08-18 19:55:13 | Re: pg_dump schema breakup |