[EMAIL PROTECTED] (Rod Taylor) wrote: > It's a fairly limited case and by no means removes the requirement for > regular vacuums, but for an update heavy structure perhaps it would be > worth while? Even if it could only keep indexes clean it would help.
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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
