From: Patrick Hatcher <pathat@comcast.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: John A Meinel <john@arbash-meinel.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Slow update statement
Date: Sun, 07 Aug 2005 21:35:36 -0700
Message-ID: <42F6E118.20206@comcast.net> (raw)
In-Reply-To: <20254.1123472905@sss.pgh.pa.us>
References: <42F4B812.7070501@comcast.net>
<42F4BC61.20102@arbash-meinel.com>
<42F6BCD3.4070600@comcast.net>
<20254.1123472905@sss.pgh.pa.us>
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@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
>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: pathat@comcast.net, tgl@sss.pgh.pa.us, john@arbash-meinel.com
Subject: Re: Slow update statement
In-Reply-To: <42F6E118.20206@comcast.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox