From: | Jasen Betts <jasen(at)xnet(dot)co(dot)nz> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: changing multiple pk's in one update |
Date: | 2009-04-15 12:43:00 |
Message-ID: | gs4kok$hdn$1@reversiblemaps.ath.cx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 2009-04-13, Stuart McGraw <smcg2297(at)frii(dot)com> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jasen Betts | 2009-04-15 12:57:20 | Re: ENUM vs DOMAIN vs FKyed loookup table |
Previous Message | Bryce Nesbitt | 2009-04-15 03:46:58 | Postgres process resident size does not drop after killing statement |