X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id CB36C52C28 for ; Mon, 8 Aug 2005 01:35:51 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 66084-02 for ; Mon, 8 Aug 2005 04:35:43 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by svr1.postgresql.org (Postfix) with ESMTP id B7C7F52B73 for ; Mon, 8 Aug 2005 01:35:41 -0300 (ADT) Received: from [127.0.0.1] (c-24-4-66-2.hsd1.ca.comcast.net[24.4.66.2]) by comcast.net (sccrmhc13) with ESMTP id <2005080804353901300dl953e>; Mon, 8 Aug 2005 04:35:39 +0000 Message-ID: <42F6E118.20206@comcast.net> Date: Sun, 07 Aug 2005 21:35:36 -0700 From: Patrick Hatcher User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: John A Meinel , "pgsql-performance@postgresql.org" Subject: Re: Slow update statement References: <42F4B812.7070501@comcast.net> <42F4BC61.20102@arbash-meinel.com> <42F6BCD3.4070600@comcast.net> <20254.1123472905@sss.pgh.pa.us> In-Reply-To: <20254.1123472905@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.719 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, DNS_FROM_RFC_WHOIS X-Spam-Level: * X-Archive-Number: 200508/60 X-Sequence-Number: 13807 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 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 > > >