| From: | Jeff <threshar(at)torgo(dot)978(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, Douglas J Hunley <doug(at)hunley(dot)homeip(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: 7 hrs for a pg_restore? |
| Date: | 2008-02-19 20:07:30 |
| Message-ID: | F80D4D50-9F3F-4CAA-B01E-B644912126D7@torgo.978.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)jefftrout(dot)com>
www.dellsmartexitin.com
www.stuarthamm.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2008-02-19 20:16:42 | Re: 7 hrs for a pg_restore? |
| Previous Message | Jeff Davis | 2008-02-19 19:51:19 | Re: 7 hrs for a pg_restore? |