Cheaper VACUUMing
От | Christopher Browne |
---|---|
Тема | Cheaper VACUUMing |
Дата | |
Msg-id | m38y6kzn4b.fsf_-_@knuth.knuth.cbbrowne.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL clustering VS MySQL clustering (Marty Scholes <marty@outputservices.com>) |
Ответы |
Re: Cheaper VACUUMing
|
Список | pgsql-performance |
A long time ago, in a galaxy far, far away, gsstark@mit.edu (Greg Stark) wrote: > Dawid Kuroczko <qnex42@gmail.com> writes: > >> Quick thought -- would it be to possible to implement a 'partial VACUUM' >> per analogiam to partial indexes? > > No. > > But it gave me another idea. Perhaps equally infeasible, but I don't see why. > > What if there were a map of modified pages. So every time any tuple > was marked deleted it could be marked in the map as modified. VACUUM > would only have to look at these pages. And if it could mark as free > every tuple that was marked as deleted then it could unmark the > page. > > The only downside I see is that this could be a source of contention > on multi-processor machines running lots of concurrent > update/deletes. I was thinking the same thing after hearing fairly extensive "pooh-poohing" of the notion of vacuuming based on all the pages in the shared cache. This "hot list page table" would probably need to be a hash table. It rather parallels the FSM, including the way that it would need to be limited in size. -- wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com'). http://cbbrowne.com/info/lsf.html Rules of the Evil Overlord #57. "Before employing any captured artifacts or machinery, I will carefully read the owner's manual." <http://www.eviloverlord.com/>
В списке pgsql-performance по дате отправления: