The problem that persists with this is that it throws in extra
processing at the time that the system is the _most_ busy doing
updates, thereby worsening latency at times when the system may
already be reeling at the load.
I think, as a result, that VACUUM will _have_ to be done
asynchronously.
What strikes me as being a useful approach would be to set up an
LRU-ordered (or perhaps unordered) queue of pages that have had tuples
"killed off" by DELETE or UPDATE.
Thus, a DELETE/UPDATE would add the page the tuple is on to the list.
"VACUUM RECENT CHANGES" (or something of the sort) could walk through
just those pages. Cleaning up indexes would require some further
reads, but that's a given.
This "architecture" would be way more supportive than the present way
vacuum works for tables which are large and which have portions that
see heavy update activity.
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/info/lisp.html
Rules of the Evil Overlord #129. "Despite the delicious irony, I will
not force two heroes to fight each other in the arena."
<http://www.eviloverlord.com/>
