Re: autovacuum next steps

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autovacuum next steps
Date: 2007-02-16 23:12:23
Message-ID: 45D63A57.50704@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera wrote:
> Matthew T. O'Connor wrote:
>> On first blush, I'm not sure I like this as it doesn't directly attack
>> the table starvation problem, and I think it could be a net loss of speed.
>>
>> VACUUM is I/O bound, as such, just sending multiple vacuum commands at a
>> DB isn't going to make things faster, you are now going to have multiple
>> processes reading from multiple tables at the same time. I think in
>> general this is a bad thing (unless we someday account for I/O made
>> available from multiple tablespaces).
>
> Yeah, I understand that. However, I think that can be remedied by using
> a reasonable autovacuum_vacuum_cost_delay setting, so that each worker
> uses less than the total I/O available. The main point of the proposal
> is to allow multiple workers on a DB while also allowing multiple
> databases to be processed in parallel.

So you are telling people to choose an autovacuum_delay so high that
they need to run multiple autovacuums at once to keep up? I'm probably
being to dramatic, but it seems inconsistent.

>> I think we can extend the current autovacuum stats to add one more
>> column that specifies "is hot" or something to that effect. Then when
>> the AV launcher sends a worker to a DB, it will first look for tables
>> marked as hot and work on them. While working on hot tables, the
>> launcher need not send any additional workers to this database, if the
>> launcher notices that a worker is working on regular tables, it can send
>> another worker which will look for hot tables to working, if the worker
>> doesn't find any hot tables that need work, then it exits leaving the
>> original working to continue plodding along.
>
> How would you define what's a "hot" table?

I wasn't clear, I would have the Admin specified it, and we can store it
as an additional column in the pg_autovacuum_settings table. Or perhaps
if the table is below some size threshold and autovacuum seems that it
needs to be vacuumed every time it checks it 10 times in a row or
something like that.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Drake 2007-02-16 23:18:15 Re: patch adding new regexp functions
Previous Message Bruce Momjian 2007-02-16 23:01:56 Re: [pgsql-patches] pg_standby