Re: [ADMIN] autovacuum on a -mostly- r/o table - Mailing list pgsql-performance

From Matthew T. O'Connor
Subject Re: [ADMIN] autovacuum on a -mostly- r/o table
Date
Msg-id 453248DA.7050806@zeut.net
Whole thread Raw
In response to Re: [ADMIN] autovacuum on a -mostly- r/o table  (Tobias Brox <tobias@nordicbet.com>)
Responses Re: [ADMIN] autovacuum on a -mostly- r/o table  (Tobias Brox <tobias@nordicbet.com>)
List pgsql-performance
Tobias Brox wrote:
> [Matthew T. O'Connor - Wed at 02:33:10PM -0400]
>
>> In addition autovacuum respects the work of manual or cron based
>> vacuums, so if you issue a vacuum right after a daily batch insert /
>> update, autovacuum won't repeat the work of that manual vacuum.
>>
>
> I was experimenting a bit with autovacuum now.  To make the least effect
> possible, I started with a too high cost_delay/cost_limit-ratio.  The
> effect of this was that autovacuum "never" finished the transactions it
> started with, and this was actually causing the nightly vacuum to not do
> it's job good enough.

Yeah, I think if the delay settings are too high it can cause problems,
that's part of the reason we have yet to turn these on be default since
we won't have enough data to suggest good values.  Can you tell us what
settings you finally settled on?

BTW hopefully for 8.3 we are going to add the concept of maintenance
windows to autovacuum, during these periods you can lower the thresholds
and perhaps even change the delay settings to make autovacuum more
aggressive during the maintenance window.  This hopefully will just
about eliminate the need for nightly cron based vacuum runs.


pgsql-performance by date:

Previous
From: Tobias Brox
Date:
Subject: Re: [ADMIN] autovacuum on a -mostly- r/o table
Next
From: Tobias Brox
Date:
Subject: Re: [ADMIN] autovacuum on a -mostly- r/o table