Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id F2B249F9FB1 for ; Wed, 25 Oct 2006 13:53:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 04238-07 for ; Wed, 25 Oct 2006 13:53:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from 66-226-76-106.dedicated.abac.net (66-226-76-106.dedicated.abac.net [66.226.76.106]) by postgresql.org (Postfix) with ESMTP id 60AF79FB258 for ; Wed, 25 Oct 2006 13:53:04 -0300 (ADT) Received: (qmail 8473 invoked by uid 2020); 25 Oct 2006 09:54:40 -0700 Received: from wsip-70-167-125-69.sd.sd.cox.net (HELO ?192.168.0.3?) (70.167.125.69) by 66-226-76-106.dedicated.abac.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Oct 2006 09:54:40 -0700 Message-ID: <453F963E.4010206@modgraph-usa.com> Date: Wed, 25 Oct 2006 09:52:14 -0700 From: "Craig A. James" User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: "Jim C. Nasby" CC: Worky Workerson , Merlin Moncure , pgsql-performance@postgresql.org Subject: Re: Best COPY Performance References: <20061023215913.GW26892@nasby.net> <20061025001709.GA26892@nasby.net> <453EF7C4.2040105@modgraph-usa.com> <20061025152209.GP26892@nasby.net> In-Reply-To: <20061025152209.GP26892@nasby.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.401 tagged_above=0 required=5 tests=AWL, HELO_DYNAMIC_IPADDR2 X-Spam-Level: ** X-Archive-Number: 200610/522 X-Sequence-Number: 21651 Jim C. Nasby wrote: > Wait... so you're using perl to copy data between two tables? And using > a cursor to boot? I can't think of any way that could be more > inefficient... > > What's wrong with a plain old INSERT INTO ... SELECT? Or if you really > need to break it into multiple transaction blocks, at least don't > shuffle the data from the database into perl and then back into the > database; do an INSERT INTO ... SELECT with that same where clause. The data are on two different computers, and I do processing of the data as it passes through the application. Otherwise, the INSERT INTO ... SELECT is my first choice. Craig