Message-ID: <4EC06D57.8020402@squeakycode.net>
Date: Sun, 13 Nov 2011 19:22:31 -0600
From: Andy Colson <andy@squeakycode.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.21) Gecko/20110903 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: contato@alexanderburbello.com.br
CC: Alexander Burbello <burbello@yahoo.com.br>, pgsql-general@postgresql.org
Subject: Re: Restore db
References: 
 <CAJcRiCWXaCnE34navMgDyT3pYVp=3XbAsp4fWjcvxFo78pFbWA@mail.gmail.com>
In-Reply-To: 
 <CAJcRiCWXaCnE34navMgDyT3pYVp=3XbAsp4fWjcvxFo78pFbWA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/13/2011 06:09 PM, Alexander Burbello wrote:
> Hi folks,
>
> My server has a daily routine to import a dump file, however its taking long time to finish it.
> The original db has around 200 MB and takes 3~4 minutes to export (there are many blob fields), however it takes 4 hours to import using pg_restore.
>
> What can I do to tune this database to speed up this restore??
>
> My current db parameters are:
> shared_buffers = 256MB
> maintenance_work_mem = 32MB
>
> Any suggestion is very welcome.
> Thank you.
> Alex

Are you doing this over a network?

If you watch it restore with vmstat (or top) are you IO bound?  If so, temporarily turn off fsync, restore the db, then turn it back on.

something like:
autovacuum = off
fsync = off
synchronous_commit = off
full_page_writes = off
bgwriter_lru_maxpages = 0


On the other hand, if you are cpu bound, use the multi-core-restore-option -j.

Or use both.

> My current db parameters are:
> shared_buffers = 256MB
> maintenance_work_mem = 32MB

This is useless information without knowing anything about your computer.  If you have 512 Meg of ram its a lot different than if you have 32 Gig.


-Andy