X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 99DB553385 for ; Wed, 4 May 2005 20:33:58 -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 35947-09 for ; Wed, 4 May 2005 23:33:49 +0000 (GMT) Received: from mail63.csoft.net (leary3.csoft.net [63.111.22.74]) by svr1.postgresql.org (Postfix) with SMTP id 7F3A352956 for ; Wed, 4 May 2005 20:33:48 -0300 (ADT) Received: (qmail 2256 invoked by uid 1112); 4 May 2005 23:33:50 -0000 Date: Wed, 4 May 2005 18:33:50 -0500 (EST) From: Kris Jurka X-X-Sender: books@leary.csoft.net To: Mischa Sandberg Cc: pgsql-performance@postgresql.org Subject: Re: COPY vs INSERT In-Reply-To: <1115248292.427956a468a55@webmail.telus.net> Message-ID: References: <21154.1115136741@sss.pgh.pa.us> <1115146397.4277c89dc37b4@webmail.telus.net> <1115246490.1709.233393619@webmail.messagingengine.com> <1115248292.427956a468a55@webmail.telus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.011 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/44 X-Sequence-Number: 12208 On Wed, 4 May 2005, Mischa Sandberg wrote: > Copy makes better use of the TCP connection for transmission. COPY uses > the TCP connection like a one-way pipe. INSERT is like an RPC: the > sender has to wait until the insert's return status roundtrips. Not true. A client may send any number of Bind/Execute messages on a prepared statement before a Sync message. So multiple inserts may be sent in one network roundtrip. This is exactly how the JDBC driver implements batch statements. There is some limit to the number of queries in flight at any given moment because there is the potential to deadlock if both sides of network buffers are filled up and each side is blocked waiting on a write. The JDBC driver has conservatively selected 256 as the maximum number of queries to send at once. Kris Jurka