Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 0FFE6633D08 for ; Wed, 15 Apr 2009 09:49:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 31754-07 for ; Wed, 15 Apr 2009 09:49:30 -0300 (ADT) X-Greylist: delayed 00:06:40.347939 by SQLgrey-1.7.6 Received: from titania.wxnz.net (titania.wxnz.net [58.28.4.13]) by mail.postgresql.org (Postfix) with ESMTP id DF8CE63252C for ; Wed, 15 Apr 2009 09:49:37 -0300 (ADT) Received: from gonzo (ip-118-90-131-169.xdsl.xnet.co.nz [118.90.131.169]) by titania.wxnz.net (Postfix) with ESMTP id 5AFD2109813E for ; Thu, 16 Apr 2009 00:42:53 +1200 (NZST) Received: from news by gonzo with local (Exim 4.69) (envelope-from ) id 1Lu4SC-0004dt-RE for pgsql-sql@postgresql.org; Thu, 16 Apr 2009 00:43:00 +1200 To: pgsql-sql@postgresql.org Path: not-for-mail From: Jasen Betts Newsgroups: gmane.comp.db.postgresql.sql Subject: Re: changing multiple pk's in one update Date: 15 Apr 2009 12:43:00 GMT Organization: Dis (not Dat) Organisation Lines: 36 Message-ID: References: <49DC1034.1060705@frii.com> <49E36E1B.6020107@frii.com> NNTP-Posting-Host: localhost Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: reversiblemaps.ath.cx 1239799380 17847 127.0.0.1 (15 Apr 2009 12:43:00 GMT) X-Face: ?)Aw4rXwN5u0~$nqKj`xPz>xHCwgi^q+^?Ri*+R(&uv2=E1Q0Zk(>h!~o2ID@6{uf8s; a +M[5[U[QT7xFN%^gR"=tuJw%TXXR'Fp~W; (T"1(739R%m0Yyyv*gkGoPA.$b,D.w:z+<'"=-lVT?6 {T?=R^:W5g|E2#EhjKCa+nt":4b}dU7GYB*HBxn&Td$@f%.kl^:7X8rQWd[NTc"P"u6nkisze/Q; 8 "9Z{peQF,w)7UjV$c|RO/mQW/NMgWfr5*$-Z%u46"/00mx-,\R'fLPe.)^ User-Agent: slrn/pre1.0.0-2 (Linux) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200904/77 X-Sequence-Number: 32423 On 2009-04-13, Stuart McGraw wrote: > Jasen Betts wrote: >> I see no reason to keep the index (and its associated UNIQUE >> constraint) during the update, AFAICT all it does is slow the process >> down. > > Thanks for the suggestion. > > Unfortunately I am doing this key renumbering in > an interactive gui app and as there are several million > rows involved, rebuilding indexes take too long. the update takes a long time too if it's updating all the rows. and updating the index piecewise at the same time. with the index extant I get from 20 (if the start and end ranges don't overlap) and 28s (with , to 28 seconds (maximum overlap) for a table with 1000000 (short) rows it takes 18 seconds if I first drop the index, then update, then restore the index. so, about the same amount of time or slightly faster by dropping the index. if wrap them in a transaction it takes 30s each way > I have continued searching for other ways to do this > but most of my google results are floating in a sea > of "update if insert fails, like mysql" results so > I still have a little hope it is possible. > I thought I remember seeing, a year or two ago, an > update statement with an ordered subquery that avoided > duplicate key errors but I am probably misrembering. maybe you can do it using a cursor? I've not looked at them yet.