From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Cheaper VACUUMing |
Date: | 2005-01-23 06:16:20 |
Message-ID: | m38y6kzn4b.fsf_-_@knuth.knuth.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
A long time ago, in a galaxy far, far away, gsstark(at)mit(dot)edu (Greg Stark) wrote:
> Dawid Kuroczko <qnex42(at)gmail(dot)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/>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-01-23 20:15:52 | Re: PostgreSQL clustering VS MySQL clustering |
Previous Message | Christopher Browne | 2005-01-23 06:08:26 | Re: PostgreSQL clustering VS MySQL clustering |