From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Resumable vacuum proposal and design overview |
Date: | 2007-02-28 11:34:27 |
Message-ID: | 1172662467.3760.932.camel@silverbirch.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2007-02-28 at 09:38 +0000, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zoltan Boszormenyi | 2007-02-28 12:04:38 | psql problem querying relations |
Previous Message | Simon Riggs | 2007-02-28 11:26:29 | Re: Resumable vacuum proposal and design overview |