Message-ID: <453F562C.60609@logix-tt.com>
Date: Wed, 25 Oct 2006 14:18:52 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: Worky Workerson <worky.workerson@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Best COPY Performance
References: <ce4072df0610201305u7836dc7bn437ec0aaf1c3e25f@mail.gmail.com>	
	<453C8B0D.4070803@logix-tt.com>
	<ce4072df0610230840r4b3df653h3144dab06bdb9ed2@mail.gmail.com>
In-Reply-To: <ce4072df0610230840r4b3df653h3144dab06bdb9ed2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Hi, Worky,

Worky Workerson wrote:

> $ psql -c "COPY my_table TO STDOUT" > my_data
> $ ls my_data
> 2018792 edgescape_pg_load
> $ time cat my_data | psql -c "COPY mytable FROM STDIN"
> real    5m43.194s
> user    0m35.412s
> sys     0m9.567s

That's via PSQL, and you get about 5 MB/Sec.

>> On a table with no indices, triggers and contstraints, we managed to
>> COPY about 7-8 megabytes/second with psql over our 100 MBit network, so
>> here the network was the bottleneck.
> 
> hmm, this makes me think that either my PG config is really lacking,
> or that the SAN is badly misconfigured, as I would expect it to
> outperform a 100Mb network.  As it is, with a straight pipe to psql
> COPY, I'm only working with a little over 5.5 MB/s.  Could this be due
> to the primary key index updates?

Yes, index updates cause both CPU load, and random disk access (which is
slow by nature).


HTH,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org