Re: pg_dump additional options for performance
От | Simon Riggs |
---|---|
Тема | Re: pg_dump additional options for performance |
Дата | |
Msg-id | 1217091402.3894.1185.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: pg_dump additional options for performance (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_dump additional options for performance
|
Список | pgsql-patches |
On Sat, 2008-07-26 at 12:20 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Fri, 2008-07-25 at 19:16 -0400, Tom Lane wrote: > >> The key problem is that pg_restore is broken: > > > The key capability here is being able to split the dump into multiple > > pieces. The equivalent capability on restore is *not* required, because > > once the dump has been split the restore never needs to be. > > This argument is nonsense. > The typical usage of this capability, IMHO, will be Arghh! That's not my stated use case!?#*! 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. Anyway, clearly time for me to stop and have a break. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-patches по дате отправления: