Re: Resumable vacuum proposal and design overview
От | Simon Riggs |
---|---|
Тема | Re: Resumable vacuum proposal and design overview |
Дата | |
Msg-id | 1172662467.3760.932.camel@silverbirch.site обсуждение исходный текст |
Ответ на | Re: Resumable vacuum proposal and design overview (Heikki Linnakangas <heikki@enterprisedb.com>) |
Ответы |
Re: Resumable vacuum proposal and design overview
|
Список | 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 по дате отправления: