Message-ID: <454620DF.1000003@kaltenbrunner.cc>
Date: Mon, 30 Oct 2006 16:57:19 +0100
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
User-Agent: Thunderbird 1.5.0.7 (X11/20060928)
MIME-Version: 1.0
To: Luke Lonergan <llonergan@greenplum.com>
CC: "Spiegelberg, Greg" <gspiegelberg@cranel.com>,
	Worky Workerson <worky.workerson@gmail.com>,
	Merlin Moncure <mmoncure@gmail.com>, pgsql-performance@postgresql.org
Subject: Re: Best COPY Performance
References: <C16B58DB.56EC%llonergan@greenplum.com>
In-Reply-To: <C16B58DB.56EC%llonergan@greenplum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Luke Lonergan wrote:
> Greg,
> 
> On 10/30/06 7:09 AM, "Spiegelberg, Greg" <gspiegelberg@cranel.com> wrote:
> 
>> I broke that file into 2 files each of 550K rows and performed 2
>> simultaneous COPY's after dropping the table, recreating, issuing a sync
>> on the system to be sure, &c and nearly every time both COPY's finish in
>> 12 seconds.  About a 20% gain to ~91K rows/second.
>>
>> Admittedly, this was a pretty rough test but a 20% savings, if it can be
>> put into production, is worth exploring for us.
> 
> Did you see whether you were I/O or CPU bound in your single threaded COPY?
> A 10 second "vmstat 1" snapshot would tell you/us.
> 
> With Mr. Workerson (:-) I'm thinking his benefit might be a lot better
> because the bottleneck is the CPU and it *may* be the time spent in the
> index building bits.
> 
> We've found that there is an ultimate bottleneck at about 12-14MB/s despite
> having sequential write to disk speeds of 100s of MB/s.  I forget what the
> latest bottleneck was.

I have personally managed to load a bit less then 400k/s (5 int columns 
no indexes) - on very fast disk hardware - at that point postgresql is 
completely CPU bottlenecked (2,6Ghz Opteron).
Using multiple processes to load the data will help to scale up to about 
  900k/s (4 processes on 4 cores).


Stefan