X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 157BAD9175 for ; Fri, 23 Sep 2005 11:33:08 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 84387-03 for ; Fri, 23 Sep 2005 14:33:03 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 1D41CD90EC for ; Fri, 23 Sep 2005 11:33:05 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j8NEX6aX003712; Fri, 23 Sep 2005 10:33:06 -0400 (EDT) To: Joost Kraaijeveld Cc: Arjen van der Meijden , Michael Stone , pgsql-performance@postgresql.org Subject: Re: How to determine cause of performance problem? In-reply-to: <1127482558.3524.23.camel@Panoramix> References: <1127458167.2475.105.camel@Panoramix> <20050923095517.GW14918@mathom.us> <1127470875.3524.17.camel@Panoramix> <20050923110500.GX14918@mathom.us> <4333E4DB.4020206@tweakers.net> <1127482558.3524.23.camel@Panoramix> Comments: In-reply-to Joost Kraaijeveld message dated "Fri, 23 Sep 2005 15:35:58 +0200" Date: Fri, 23 Sep 2005 10:33:06 -0400 Message-ID: <3711.1127485986@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 required=5 tests=[AWL=0.006] X-Spam-Level: X-Archive-Number: 200509/295 X-Sequence-Number: 14603 Joost Kraaijeveld writes: > I will test this a for perfomance improvement, but still, I wonder if ~ > 100 inserts/second is a reasonable performance for my software/hardware > combination. Is the client code running on the same machine as the database server? If not, what's the network delay and latency between them? The major problem you're going to have here is at least one network round trip per row inserted --- possibly more, if the jdbc driver is doing "helpful" stuff behind your back like starting/committing transactions. regards, tom lane