| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Patrick Hatcher <pathat(at)comcast(dot)net> |
| Cc: | John A Meinel <john(at)arbash-meinel(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Slow update statement |
| Date: | 2005-08-08 03:48:25 |
| Message-ID: | 20254.1123472905@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Patrick Hatcher <pathat(at)comcast(dot)net> writes:
> Hash Join (cost=1246688.42..4127248.31 rows=12702676 width=200)
> Hash Cond: ("outer".cus_num = "inner".cus_nbr)
> -> Seq Scan on bcp_ddw_ck_cus b (cost=0.00..195690.76 rows=12702676
> width=16)
> -> Hash (cost=874854.34..874854.34 rows=12880834 width=192)
> -> Seq Scan on cdm_ddw_customer (cost=0.00..874854.34
> rows=12880834 width=192)
Yipes, that's a bit of a large hash table, if the planner's estimates
are on-target. What do you have work_mem (sort_mem if pre 8.0) set to,
and how does that compare to actual available RAM? I'm thinking you
might have set work_mem too large and the thing is now swap-thrashing.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Hatcher | 2005-08-08 04:35:36 | Re: Slow update statement |
| Previous Message | Patrick Hatcher | 2005-08-08 02:09:04 | Re: Slow update statement |