> > # 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. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings