Re: pg_dump additional options for performance
От | Simon Riggs |
---|---|
Тема | Re: pg_dump additional options for performance |
Дата | |
Msg-id | 1204046211.4252.363.camel@ebony.site обсуждение исходный текст |
Ответ на | Re: pg_dump additional options for performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump additional options for performance
Re: pg_dump additional options for performance |
Список | pgsql-hackers |
On Tue, 2008-02-26 at 10:48 -0500, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > My thinking is to do either: > > * keep it as simple as possible to allow DBA to manually improve > > performance > > * express dependency information in the pg_dump output to allow some > > level of parallelism to use that information to advantage automatically > > I'm astonished at how much pontificating is going on in this thread > from people who seem unaware of what pg_dump *already* does. > > If you don't already know exactly what is in an -Fc dump, you are > unqualified to be discussing how to improve it. I've not been advocating improving pg_restore, which is where the -Fc tricks come in. pg_dump can write text files that can be input to psql. pg_dump already has the dependency information *but* it doesn't write the dependency info to a psql-able file. But it could, which is what I meant. If we created a grammar for psql that allowed dependency information to be expressed then pg_dump and pg_restore could generate scripts with their dependency info expressed in the psql grammar. I see you thought I meant pg_restore. I don't thinking extending pg_restore in that way is of sufficiently generic use to make it worthwhile. Extending psql would be worth it, since not all psql scripts come from pg_dump. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: