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 "[EMAIL PROTECTED]" "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/> ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
