Re: 12 hour table vacuums - Mailing list pgsql-performance

From Ron St-Pierre
Subject Re: 12 hour table vacuums
Date
Msg-id 471E249C.2090009@shaw.ca
Whole thread Raw
In response to Re: 12 hour table vacuums  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
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
>
>


pgsql-performance by date:

Previous
From: Bill Moran
Date:
Subject: Re: 12 hour table vacuums
Next
From: Ron St-Pierre
Date:
Subject: Re: 12 hour table vacuums