Re: atrocious update performance

> > # explain update account.cust set prodid = tempprod.prodid
> >     where tempprod.did = origid;

> >  Merge Join  (cost=0.00..232764.69 rows=4731410 width=252)
> >    Merge Cond: (("outer".origid)::text = ("inner".did)::text)
> >    ->  Index Scan using ix_origid on cust  (cost=0.00..94876.83
> >        rows=4731410 width=244)
> >    ->  Index Scan using ix_did on tempprod  (cost=0.00..66916.71
> >        rows=4731410 width=18)

> I'm going to hazard a guess and say you have a number of foreign keys
> that refer to account.cust.prodid? This is probably the time consuming
> part -- perhaps even a missing index on one of those keys
> that refers to
> this field.

Actually, there are no foreign keys to those columns.  Once they're
populated, I'll apply a foreign key constraint and they'll refer to the
appropriate row in the prod and subprod tables, but nothing will
reference account.cust.[sub]prodid.  There are, of course, several foreign
keys referencing account.cust.custid.

> Going the other way should be just as good for your purposes, and much
> faster since you're not updating several foreign key'd fields bound to
> account.cust.prodid.

> UPDATE tempprod.prodid = prodid
>   FROM account.cust
>  WHERE temprod.did = cust.origid;

Not quite. Without this update, acount.cust.[sub]prodid are null.  The
data was strewn across multiple tables in MS SQL; we're normalizing it
into one, hence the need to populate the two columns independently.

/rls

--
Rosser Schwarz
Total Card, Inc.