Tom Lane wrote: > "J. R. Nield" <[EMAIL PROTECTED]> writes: > >> I do not think that is the case; and anyway we've pretty much rejected > >> Vadim's notion of going to an Oracle-style UNDO buffer. > > > Could someone point me to this discussion, or summarize what the problem > > was? > > I'm too lazy to dig through the archives at the moment, but the main > points were (a) a finite-size UNDO buffer chokes on large transactions > and (b) the Oracle approach requires live transaction processing to > do the cleanup work that our approach can push off to hopefully-not- > time-critical vacuum processing. > > UNDO per se doesn't eliminate VACUUM anyhow; it only reclaims space > from tuples written by aborted transactions. If you want to get rid > of VACUUM then you need another way to get rid of the old versions of > perfectly good committed tuples that are obsoleted by updates from > later transactions. That essentially means you need an overwriting > storage manager, which is a concept that doesn't mix well with MVCC. > > Oracle found a solution to that conundrum, but it's really not obvious > to me that their solution is better than ours. Also, they have > patents that we'd probably run afoul of if we try to imitate their > approach too closely.
Don't forget reclaiming space from transactions that delete tuples. UNDO doesn't help there either. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(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
