Date: Tue, 23 Oct 2007 09:43:08 -0700
From: Ron St-Pierre <ron.pgsql@shaw.ca>
Subject: Re: 12 hour table vacuums
In-reply-to: <19338.1193155911@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Message-id: <471E249C.2090009@shaw.ca>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <471E18ED.3090704@shaw.ca> <19338.1193155911@sss.pgh.pa.us>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)

Tom Lane wrote:
> Here is your problem:
>
>   
>> vacuum_cost_delay = 200
>>     
>
> If you are only vacuuming when nothing else is happening, you shouldn't
> be using vacuum_cost_delay at all: set it to 0.  In any case this value
> is probably much too high.  I would imagine that if you watch the
> machine while the vacuum is running you'll find both CPU and I/O load
> near zero ... which is nice, unless you would like the vacuum to finish
> sooner.
>   
Yeah, I've noticed that CPU, mem and I/O load are really low when this 
is running. I'll change that setting.
> In unrelated comments:
>
>   
>> maintenance_work_mem = 786432
>>     
>
> That seems awfully high, too.
>
>   
Any thoughts on a more reasonable value?
>> max_fsm_pages = 70000
>>     
>
> And this possibly too low --- 
The default appears to be 20000, so I upped it to 70000. I'll try 160000 
(max_fsm_relations*16).
> are you sure you are not leaking disk
> space?
>
>   
What do you mean leaking disk space?
>> stats_start_collector = off
>> stats_command_string = on
>> stats_block_level = on
>> stats_row_level = on    
>>     
>
> These are not self-consistent.
>
> 			regards, tom lane
>
>