Re: 7 hrs for a pg_restore?
От | Douglas J Hunley |
---|---|
Тема | Re: 7 hrs for a pg_restore? |
Дата | |
Msg-id | 200802191555.43340.doug@hunley.homeip.net обсуждение исходный текст |
Ответ на | Re: 7 hrs for a pg_restore? (Jeff <threshar@torgo.978.org>) |
Ответы |
Re: 7 hrs for a pg_restore?
|
Список | pgsql-performance |
On Tuesday 19 February 2008 15:07:30 Jeff wrote: > On Feb 19, 2008, at 1:22 PM, Tom Lane wrote: > > maintenance_work_mem, to be more specific. If that's too small it > > will > > definitely cripple restore speed. I'm not sure fsync would make much > > difference, but checkpoint_segments would. See > > http://www.postgresql.org/docs/8.3/static/populate.html#POPULATE-PG- > > DUMP > > I wonder if it would be worthwhile if pg_restore could emit a warning > if maint_work_mem is "low" (start flamewar on what "low" is). > > And as an addition to that - allow a cmd line arg to have pg_restore > bump it before doing its work? On several occasions I was moving a > largish table and the COPY part went plenty fast, but when it hit > index creation it slowed down to a crawl due to low maint_work_mem.. fwiw, I +1 this now that I have a (minor) understanding of what's going on, I'd love to do something like: pg_restore -WM $large_value <normal options> -- Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778 http://doug.hunley.homeip.net There are no dead students here. This week.
В списке pgsql-performance по дате отправления: