Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 05A0D9FB295 for ; Tue, 6 Mar 2007 04:13:52 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 36424-03 for ; Tue, 6 Mar 2007 04:13:47 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 270289FB290 for ; Tue, 6 Mar 2007 04:13:47 -0400 (AST) Received: from server3.office.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 417E3768D0; Tue, 6 Mar 2007 08:08:30 +0000 (GMT) Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id 145D927408E; Tue, 6 Mar 2007 08:08:30 +0000 (GMT) Message-ID: <45ED217D.30404@archonet.com> Date: Tue, 06 Mar 2007 08:08:29 +0000 From: Richard Huxton User-Agent: IceDove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: =?ISO-8859-1?Q?jo=EBl_Winteregg?= Cc: pgsql-performance@postgresql.org Subject: Re: Insert performance References: <1172596221.393824.41130@j27g2000cwj.googlegroups.com> <45ED1996.7050008@archonet.com> <1173167607.4917.8.camel@hatman> In-Reply-To: <1173167607.4917.8.camel@hatman> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.206 tagged_above=0 required=5 tests=AWL, BAYES_50, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200703/122 X-Sequence-Number: 23527 joël Winteregg wrote: > Hi Richard, > >>> Here is my problem. With some heavy insert into a simple BD (one >>> table, no indexes) i can't get better perf than 8000 inserts/sec. I'm >>> testing it using a simple C software which use libpq and which use: >>> - Insert prepared statement (to avoid too many request parsing on the >>> server) >>> - transaction of 100000 inserts >> Are each of the INSERTs in their own transaction? >> > > No, as said above transactions are made of 100000 inserts... Hmm - I read that as just meaning "inserted 100000 rows". You might find that smaller batches provide peak performance. >> If so, you'll be limited by the speed of the disk the WAL is running on. >> >> That means you have two main options: >> 1. Have multiple connections inserting simultaneously. > > Yes, you're right. That what i have been testing and what provide the > best performance ! I saw that postgresql frontend was using a lot of CPU > and not both of them (i'm using a pentium D, dual core). To the opposit, > the postmaster process use not much resources. Using several client, > both CPU are used and i saw an increase of performance (about 18000 > inserts/sec). > > So i think my bottle neck is more the CPU speed than the disk speed, > what do you think ? Well, I think it's fair to say it's not disk. Let's see - the original figure was 8000 inserts/sec, which is 0.125ms per insert. That sounds plausible to me for a round-trip to process a simple command - are you running the client app on the same machine, or is it over the network? Two other things to bear in mind: 1. If you're running 8.2 you can have multiple sets of values in an INSERT http://www.postgresql.org/docs/8.2/static/sql-insert.html 2. You can do a COPY from libpq - is it really not possible? -- Richard Huxton Archonet Ltd