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  (Patrick Hatcher <pathat@comcast.net>)
Список 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 по дате отправления:

Предыдущее
От: Patrick Hatcher
Дата:
Сообщение: Re: Slow update statement
Следующее
От: Patrick Hatcher
Дата:
Сообщение: Re: Slow update statement