Re: atrocious update performance
От | Rod Taylor |
---|---|
Тема | Re: atrocious update performance |
Дата | |
Msg-id | 1079387674.33643.12.camel@jester обсуждение исходный текст |
Ответ на | Re: atrocious update performance ("Rosser Schwarz" <rschwarz@totalcardinc.com>) |
Список | pgsql-performance |
On Mon, 2004-03-15 at 16:15, Rosser Schwarz wrote: > > > # 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. If there are no feign keys to it, I wouldn't expect it to take more than 10 minutes on slow hardware. Fresh out of ideas here.
В списке pgsql-performance по дате отправления: