"J. R. Nield" <jrnield@usol.com> 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.
regards, tom lane