Re: Autovacuum to-do list

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autovacuum to-do list
Date: 2005-07-28 01:42:22
Message-ID: Pine.LNX.4.58.0507281034240.32271@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 27 Jul 2005, Alvaro Herrera wrote:

> Hackers,
>
> This is a list of things people mentioned as interesting to do for
> vacuum/autovacuum, during the last autovacuum discussion thread. Some
> of them are wishful thinking, others are doable.
>
> Neil, Gavin: both of you mentioned that you didn't like autovacuum as a
> long term solution. May I ask you if you have more suggestions for this
> list?

My argument against autovacuum integration was more about the fact that we
shouldn't automate vacuuming in the backend until the cost of vacuum
reduces significantly. The fact is that it has been integrated so I think
the following might be worth considering:

* Change how we track the need to vacuum

I don't really think the use of row level stats are the best
indicator for a need to vacuum. I wonder if we could keep a
counter for each segment (ie, every 1 GB file backing a heap or
index) or file which indicates the number of blocks which have been
dirtied since the last vacuum. The user would specify a threshold
of X blocks and once we reached that we would invoke vacuum.

This means we can do without row level stats, I think, at the
expense of having to maintain state in shared memory for each
table and index (or segment). I'm not sure if that is a good
trade off or not but it reminds me of counting cards in blackjack
-- and good things always come of that ;-).

That's all I can think of at the moment.

Thanks,

Gavin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2005-07-28 02:32:34 Re: [Testperf-general] dbt2 & opteron performance
Previous Message Neil Conway 2005-07-28 01:40:52 Re: Some new list.c primitives