Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 674542E0030 for ; Thu, 5 Jun 2008 03:18:45 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 55275-01 for ; Thu, 5 Jun 2008 03:18:37 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail01.enterprisedb.com (webmail.enterprisedb.com [63.246.7.168]) by developer.postgresql.org (Postfix) with ESMTP id ED9B02E002C for ; Thu, 5 Jun 2008 03:18:38 -0300 (ADT) thread-index: AcjG1BlQB3PJJ47JQt6RhbN5q+MFDg== Received: from [192.168.1.105] ([82.181.212.226]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 02:19:21 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Message-ID: <48478535.2010905@enterprisedb.com> Date: Thu, 05 Jun 2008 09:18:29 +0300 From: "Heikki Linnakangas" Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.12 (X11/20080420) MIME-Version: 1.0 To: "andrew klassen" Cc: "James Mansion" , Subject: Re: insert/update tps slow with indices on table > 1M rows References: <354284.6724.qm@web37304.mail.mud.yahoo.com> In-Reply-To: <354284.6724.qm@web37304.mail.mud.yahoo.com> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2008 06:19:23.0156 (UTC) FILETIME=[18CDB540:01C8C6D4] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/33 X-Sequence-Number: 30383 andrew klassen wrote: > I am using the c-library interface and for these particular transactions > I preload PREPARE statements. Then as I get requests, I issue a BEGIN, > followed by at most 300 EXECUTES and then a COMMIT. That is the > general scenario. What value beyond 300 should I try? Make sure you use the asynchronous PQsendQuery, instead of plain PQexec. Otherwise you'll be doing a round-trip for each EXECUTE anyway regardless of the batch size. Of course, if the bottleneck is somewhere else, it won't make a difference.. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com