On Sat, April 2, 2011 22:30, Tom Lane wrote:
>> Have you tried upping the aggressiveness of autovacuum?
>>
>
> I'm wondering about poor selection of the cost_delay settings in
> particular. It's quite easy to slow autovacuum to the point that it takes
> forever to do anything.
It's been on the default 20ms. Now giving 0 a try. In our app responsiveness
is less of a concern since we don't have human interaction. Reliability is a
greater concern.
> It's also possible that Henry is getting bit by the bug fixed here:
>
>
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Branch: master [b58c25055] 2010-11-19 22:28:20 -0500
> Branch: REL9_0_STABLE Release: REL9_0_2 [b5efc0940] 2010-11-19 22:28:25 -0500
> Branch: REL8_4_STABLE Release: REL8_4_6 [fab2af30d] 2010-11-19 22:28:30 -0500
> Branch: REL8_3_STABLE Release: REL8_3_13 [6cb9d5113] 2010-11-19 22:28:35 -0500
>
>
> Fix leakage of cost_limit when multiple autovacuum workers are active.
I'm using 9.0.3, and typically (when things eventually deteriorate to a
impending-wraparound situation) there are at least 2 and sometimes a few more
autovac procs running - some of them for weeks).
Anyway, time will now tell whether a cost_delay of 0 and some more SSDs will
help prevent hitting the wraparound wall.
Cheers
h
