Re: Config for fast huge cascaded updates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig de Stigter <craig(dot)destigter(at)koordinates(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Config for fast huge cascaded updates
Date: 2017-06-26 22:36:56
Message-ID: 24005.1498516616@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Craig de Stigter <craig(dot)destigter(at)koordinates(dot)com> writes:
> We're doing a large migration on our site which involves changing most of
> the primary key values. We've noticed this is a *very* slow process.

> Firstly we've set up all the foreign keys to use `on update cascade`. Then
> we essentially do this on every table:

> UPDATE TABLE users SET id = id + 1000000;

> Since this cascades via about 40 foreign keys to most of the other tables
> in the database, this update on our fairly small table takes about five
> hours.

Do you have indexes on all the referencing columns?

The core problem here is that the updates will be cascaded one row at a
time. As long as the referencing rows can be found by an indexscan,
that might be tolerable, but it's certainly not as fast as a bulk
update.

If you can guarantee no other updates while you're doing the migration,
it might be practical to drop the foreign key constraints, run all the
bulk updates by hand (on referencing tables too!), and then re-establish
the constraints. Of course there's a lot of potential for errors of
omission here, but if you can script it and test the script in advance,
it's worth considering.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim Fulton 2017-06-26 23:13:39 Re: When inserting from a SELECT with an ORDER BY, are the inserts (and associated triggers) applied in order?
Previous Message Craig de Stigter 2017-06-26 22:17:49 Config for fast huge cascaded updates