From: | Rod Taylor <pg(at)rbt(dot)ca> |
---|---|
To: | Rosser Schwarz <rschwarz(at)totalcardinc(dot)com> |
Cc: | 'Postgresql Performance' <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: atrocious update performance |
Date: | 2004-03-15 21:54:35 |
Message-ID: | 1079387674.33643.12.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Robert Norris | 2004-03-15 22:47:50 | Re: Scaling further up |
Previous Message | Tom Lane | 2004-03-15 21:46:54 | Re: High CPU with 7.4.1 after running for about 2 weeks |