Re: tuning autovacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: tuning autovacuum
Date: 2011-10-14 17:31:39
Message-ID: CA+TgmoaP5RxU=oWusj2vz9eZ4WtWGRZq0mniGjfbs7deVkqwBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 14, 2011 at 12:59 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Ideally we would have something like checkpoint_warning that warns users
>> in the log when there are too few autovacuum workers and cleanup is
>> being delayed.
>
> I don't think that any table-stats based approach is going to work.  I
> think you need to measure the queue of tables which need autovacuuming.
>  So you do something like:
>
> If > 10% of tables and > 10 tables need autovac/autoanalyze for more
> than one polling interval in a row, then emit a warning.
>
> Note that there are solutions other than adding workers; the user could
> also lower the polling interval, decrease vacuum_delay, or do other
> things to make autovac faster.
>
> This would require tracking stats about the size of the autovac queue.

Right. It's my feeling that that's exactly what we need to do. It's
similar to what we already do for checkpoint spreading, except applied
to a different system maintenance activity. What would be really neat
is if we could not just detect the problem, but actually adjust the
cost delay on the fly to try to fix it - again, like we do with
checkpoints.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-10-14 17:34:04 Re: Bugs in information_schema.referential_constraints view
Previous Message Josh Berkus 2011-10-14 17:27:00 Re: Call stacks and RAISE INFO