Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.



In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group