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 A1DC1542B5 for ; Thu, 5 May 2005 01:41: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 82154-06 for ; Thu, 5 May 2005 04:41:48 +0000 (GMT) Received: from priv-edtnes51.telusplanet.net (outbound04.telus.net [199.185.220.223]) by svr1.postgresql.org (Postfix) with ESMTP id 37D7153CA3 for ; Thu, 5 May 2005 01:41:47 -0300 (ADT) Received: from localhost ([199.185.220.240]) by priv-edtnes51.telusplanet.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050505044146.TWXG16460.priv-edtnes51.telusplanet.net@localhost> for ; Wed, 4 May 2005 22:41:46 -0600 Received: from 64.180.225.200 ( [64.180.225.200]) as user a3a18850@192.168.200.1 by webmail.telus.net with HTTP; Wed, 4 May 2005 21:41:46 -0700 Message-ID: <1115268106.4279a40a7481a@webmail.telus.net> Date: Wed, 4 May 2005 21:41:46 -0700 From: Mischa Sandberg To: pgsql-performance@postgresql.org Subject: Re: COPY vs INSERT References: <21154.1115136741@sss.pgh.pa.us> <1115146397.4277c89dc37b4@webmail.telus.net> <1115246490.1709.233393619@webmail.messagingengine.com> <1115248292.427956a468a55@webmail.telus.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1-cvs X-Originating-IP: 64.180.225.200 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.056 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_POST, FORGED_RCVD_HELO X-Spam-Level: * X-Archive-Number: 200505/47 X-Sequence-Number: 12211 Quoting Kris Jurka : > 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. Hunh. Interesting optimization in the JDBC driver. I gather it is sending a string of (;)-separated inserts. Sounds like efficient-but-risky stuff we did for ODBC drivers at Simba ... gets interesting when one of the insert statements in the middle fails. Good to know. Hope that the batch size is parametric, given that you can have inserts with rather large strings bound to 'text' columns in PG --- harder to identify BLOBs when talking to PG, than when talking to MSSQL/Oracle/Sybase. -- Engineers think equations approximate reality. Physicists think reality approximates the equations. Mathematicians never make the connection.