From: Alan Hodgson <ahodgson@simkin.ca>
Organization: Simkin Network Consulting
To: pgsql-performance@postgresql.org
Subject: Re: Improve COPY performance for large data sets
Date: Wed, 10 Sep 2008 10:14:34 -0700
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
References: <48C7FA69.1080507@brightbuilders.com>
In-Reply-To: <48C7FA69.1080507@brightbuilders.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200809101014.34249@hal.medialogik.com>

On Wednesday 10 September 2008, Ryan Hansen <ryan.hansen@brightbuilders.com> 
wrote:
>Currently it's taking about 12 hours to complete on a 64 bit
> server with 3 GB memory allocated (shared_buffer), single SATA 320 GB
> drive.  I don't seem to get any improvement running the same operation
> on a dual opteron dual-core, 16 GB server.
>
> I'm not asking for someone to solve my problem, just some direction in
> the best ways to tune for faster bulk loading, since this will be a
> fairly regular operation for our application (assuming it can work this
> way).  I've toyed with the maintenance_work_mem and some of the other
> params, but it's still way slower than it seems like it should be.
> So any contributions are much appreciated.

Your drive subsystem, such as it is, is inappropriate for a database. Your 
bottleneck is your drive. 

Turning fsync off might help. You should also drop all indexes on the table 
before the COPY and add them back after (which would eliminate a lot of 
random I/O during the COPY).

-- 
Alan