Re: Resumable vacuum proposal and design overview - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Resumable vacuum proposal and design overview
Date
Msg-id 1172662467.3760.932.camel@silverbirch.site
Whole thread Raw
In response to Re: Resumable vacuum proposal and design overview  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Resumable vacuum proposal and design overview  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
On Wed, 2007-02-28 at 09:38 +0000, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Galy Lee <lee.galy@oss.ntt.co.jp> writes:
> >> If we can stop at any point, we can make maintenance memory large
> >> sufficient to contain all of the dead tuples, then we only need to
> >> clean index for once. No matter how many times vacuum stops,
> >> indexes are cleaned for once.
> > 
> > I beg your pardon?  You're the one who's been harping on the
> > table-so-large-it-takes-days-to-vacuum scenario.  How you figure that
> > you can store all the dead TIDs in working memory?
> 
> This reminds me of an idea I had while looking at the bitmap index 
> patch: We could store the dead TIDs more efficiently in a bitmap, 
> allowing tables to be vacuumed in lesser cycles.
> 
> Of course, that's orthogonal to the above discussion.

I like the idea. 

How much memory would it save during VACUUM on a 1 billion row table
with 200 million dead rows? Would that reduce the number of cycles a
normal non-interrupted VACUUM would perform?

Would it work efficiently for all of the current index AMs? Each index
might use the index slightly differently during cleanup, I'm not sure.

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




pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Resumable vacuum proposal and design overview
Next
From: Zoltan Boszormenyi
Date:
Subject: psql problem querying relations