On Feb 19, 2008, at 2:55 PM, Douglas J Hunley wrote:
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>
pg_restore is a postgres client app that uses libpq to connect and,
thus, will pick up anything in your $PGOPTIONS env variable. So,
PGOPTONS="-c maintenance_work_mem=512MB" && pg_restore ....
Erik Jones
DBA | Emma®
erik@xxxxxxxxxx
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
