From: | Patrick Hatcher <pathat(at)comcast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 04:35:36 |
Message-ID: | 42F6E118.20206@comcast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
At the time this was the only process running on the box so I set
sort_mem= 228000;
It's a 12G box.
Tom Lane wrote:
>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 | Kari Lavikka | 2005-08-08 12:03:21 | Re: Finding bottleneck |
Previous Message | Tom Lane | 2005-08-08 03:48:25 | Re: Slow update statement |