Re: [HACKERS] Autovacuum Improvements

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Russell Smith" <mr-russ(at)pws(dot)com(dot)au>
Cc: "Darcy Buskermolen" <darcyb(at)commandprompt(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, "Pavan Deolasee" <pavan(at)enterprisedb(dot)com>, "Christopher Browne" <cbbrowne(at)acm(dot)org>, <pgsql-general(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Autovacuum Improvements
Date: 2007-01-21 12:24:38
Message-ID: 1169382278.3776.147.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Sat, 2007-01-20 at 09:41 +1100, Russell Smith wrote:
> Darcy Buskermolen wrote:
> > [snip]
> >
> > Another thought, is it at all possible to do a partial vacuum? ie spend the
> > next 30 minutes vacuuming foo table, and update the fsm with what hew have
> > learned over the 30 mins, even if we have not done a full table scan ?
> >
> There was a proposal for this, but it was dropped on 2 grounds.
> 1. partial vacuum would mean that parts of the table are missed, the
> user could never vacuum certain parts and transaction wraparound would
> get you. You may also have other performance issues as you forgot
> certian parts of the table

Partial vacuum would still be possible if you remembered where you got
to in the VACUUM and then started from that same point next time. It
could then go to the end of the table and wrap back around.

> 2. Index cleanup is the most expensive part of vacuum. So doing a
> partial vacuum actually means more I/O as you have to do index cleanup
> more often.

Again, not necessarily. A large VACUUM can currently perform more than
one set of index scans, so if you chose the right stopping place for a
partial VACUUM you need never incur any additional work. It might even
save effort in the long run.

I'm not necessarily advocating partial VACUUM, just pointing out that
the problems you raise need not be barriers to implementation, should
that be considered worthwhile.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message imageguy 2007-01-21 12:56:23 Using transactions with plpythonu
Previous Message Heikki Linnakangas 2007-01-21 11:39:45 Re: [HACKERS] Autovacuum Improvements

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2007-01-21 13:44:10 Re: [HACKERS] Autovacuum Improvements
Previous Message Heikki Linnakangas 2007-01-21 11:39:45 Re: [HACKERS] Autovacuum Improvements