From: | Douglas J Hunley <doug(at)hunley(dot)homeip(dot)net> |
---|---|
To: | Jeff <threshar(at)threshar(dot)is-a-geek(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 7 hrs for a pg_restore? |
Date: | 2008-02-19 20:55:43 |
Message-ID: | 200802191555.43340.doug@hunley.homeip.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2008-02-19 21:32:02 | Re: 7 hrs for a pg_restore? |
Previous Message | JP Fletcher | 2008-02-19 20:21:16 | Re: Fwd: wal_sync_methods for AIX |