Re: 7 hrs for a pg_restore?
От | Jeff |
---|---|
Тема | Re: 7 hrs for a pg_restore? |
Дата | |
Msg-id | F80D4D50-9F3F-4CAA-B01E-B644912126D7@torgo.978.org обсуждение исходный текст |
Ответ на | Re: 7 hrs for a pg_restore? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 7 hrs for a pg_restore?
Re: 7 hrs for a pg_restore? |
Список | pgsql-performance |
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.. -- Jeff Trout <jeff@jefftrout.com> www.dellsmartexitin.com www.stuarthamm.net
В списке pgsql-performance по дате отправления: