Re: Slow update statement
От | Tom Lane |
---|---|
Тема | Re: Slow update statement |
Дата | |
Msg-id | 20254.1123472905@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Slow update statement (Patrick Hatcher <pathat@comcast.net>) |
Ответы |
Re: Slow update statement
|
Список | pgsql-performance |
Patrick Hatcher <pathat@comcast.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
В списке pgsql-performance по дате отправления: