Re: pg_dump schema breakup
От | Tom Lane |
---|---|
Тема | Re: pg_dump schema breakup |
Дата | |
Msg-id | 24553.1155932458@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_dump schema breakup (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pg_dump schema breakup
|
Список | 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 по дате отправления: