Skip site navigation (1) Skip section navigation (2)

Re: 7 hrs for a pg_restore?

From: Erik Jones <erik(at)myemma(dot)com>
To: Douglas J Hunley <doug(at)hunley(dot)homeip(dot)net>
Cc: Jeff <threshar(at)threshar(dot)is-a-geek(dot)com>, 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 21:32:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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
>>> 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®
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at

In response to


pgsql-performance by date

Next:From: Dan LangilleDate: 2008-02-19 21:58:19
Subject: Re: wal_sync_methods for AIX
Previous:From: Douglas J HunleyDate: 2008-02-19 20:55:43
Subject: Re: 7 hrs for a pg_restore?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group