Message-Id: <4D8327FD020000250003BA92@gw.wicourts.gov>
Date: Fri, 18 Mar 2011 09:38:05 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Michael Andreasen" <michael@dunlops.com>,
	"Andy Colson" <andy@squeakycode.net>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: Fastest pq_restore?
References: <AANLkTi=x88_1hTotWNkw8XAGxt2iXs1JmW0WZ4sCtWXm@mail.gmail.com>
	<4D82B075.7070202@squeakycode.net>
In-Reply-To: <4D82B075.7070202@squeakycode.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Andy Colson <andy@squeakycode.net> wrote:
> On 03/17/2011 09:25 AM, Michael Andreasen wrote:
 
>> I've been looking around for information on doing a pg_restore as
>> fast as possible.

>> I am using a twin processor box with 2GB of memory
 
>> shared_buffers = 496MB
 
Probably about right.
 
>> maintenance_work_mem = 160MB
 
You might get a benefit from a bit more there; hard to say what's
best with so little RAM.
 
>> checkpoint_segments = 30
 
This one is hard to call without testing.  Oddly, some machines do
better with the default of 3.  Nobody knows why.
 
>> autovacuum = false
>> full_page_writes=false
 
Good.
 
> fsync = off
> synchronous_commit = off
 
Absolutely.
 
> bgwriter_lru_maxpages = 0
 
I hadn't thought much about that last one -- do you have benchmarks
to confirm that it helped with a bulk load?
 
You might want to set max_connections to something lower to free up
more RAM for caching, especially considering that you have so little
RAM.
 
-Kevin