Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 348242E00E2 for ; Sun, 16 Dec 2007 01:30:38 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 88523-04 for ; Sun, 16 Dec 2007 01:29:44 -0400 (AST) Received: from pillette.com (adsl-67-119-5-202.dsl.snfc21.pacbell.net [67.119.5.202]) by postgresql.org (Postfix) with ESMTP id 8A4172E3602 for ; Sun, 16 Dec 2007 01:21:53 -0400 (AST) Received: (from andrew@localhost) by pillette.com (8.11.6/8.11.6) id lBG5Llf25219; Sat, 15 Dec 2007 21:21:47 -0800 Date: Sat, 15 Dec 2007 21:21:47 -0800 From: andrew@pillette.com Message-Id: <200712160521.lBG5Llf25219@pillette.com> Subject: Re: update 600000 rows To: okparanoid@free.fr Cc: pgsql-performance@postgresql.org X-Originating-IP: 71.135.62.60 X-Mailer: Webmin 0.940 MIME-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Archive-Number: 200712/238 X-Sequence-Number: 28054 Loïc Marteau wrote .. > Steve Crawford wrote: > > If this > > is correct, I'd first investigate simply loading the csv data into a > > temporary table, creating appropriate indexes, and running a single > > query to update your other table. My experience is that this is MUCH faster. My predecessor in my current position was doing an update from a csv file line by line with perl. That is one reason he is my predecessor. Performance did not justify continuing his contract. > i can try this. The problem is that i have to make an insert if the > update don't have affect a rows (the rows don't exist yet). The number > of rows affected by insert is minor regards to the numbers of updated > rows and was 0 when i test my script). I can do with a temporary table > : update all the possible rows and then insert the rows that are in > temporary table and not in the production table with a 'not in' > statement. is this a correct way ? That's what I did at first, but later I found better performance with a TRIGGER on the permanent table that deletes the target of an UPDATE, if any, before the UPDATE. That's what PG does anyway, and now I can do the entire UPDATE in one command.