Message-ID: <42D7069B.5090107@telogis.com>
Date: Fri, 15 Jul 2005 12:43:07 +1200
From: David Mitchell <david.mitchell@telogis.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Dennis <dennis@works4me.com>
Cc: Qingqing Zhou <zhouqq@cs.toronto.edu>,
	pgsql-performance@postgresql.org
Subject: Re: performance problems ... 100 cpu utilization
References: <42D567DB.6000100@works4me.com> <db4l9c$1g4t$1@news.hub.org>
	<42D5DBEB.4010503@works4me.com> <42D5F315.3090301@telogis.com>
	<42D60C2E.3020004@works4me.com>
In-Reply-To: <42D60C2E.3020004@works4me.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

If your table has got into this state, then vacuum analyze won't fix it. 
You will have to do a vacuum full to get it back to normal, then 
regularly vacuum (not full) to keep it in good condition. We vacuum our 
critical tables every 10 minutes to keep them in good nick.

David

Dennis wrote:
> David Mitchell wrote:
> 
>> What is the load average on this machine? Do you do many updates? If 
>> you do a lot of updates, perhaps you haven't vacuumed recently. We 
>> were seeing similar symptoms when we started load testing our stuff 
>> and it turned out we were vacuuming too infrequently.
> 
> 
> The load average at the 100% utilization point was about 30! A vacuum 
> analyze was done before the test was started. I believe there are many 
> more selects than updates happening at any one time.
> 
> Dennis
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
> 
> 


-- 
David Mitchell
Software Engineer
Telogis