> > The ratio in a well tuned system should well favor outdated tuples.
> > If someone ever adds "dirty read" it is also not the case that it
> > is guaranteed, that nobody accesses the tuple you currently want
> > to undo. So I really miss to see the big difference.
>
> It will not be guaranteed anyway as soon as we start removing
> tuples without exclusive access to relation.
>
> And, I cannot say that I would implement UNDO because of
> 1. (cleanup) OR 2. (savepoints) OR 4. (pg_log management)
> but because of ALL of 1., 2., 4.
OK, I understand your reasoning here, but I want to make a comment.
Looking at the previous features you added, like subqueries, MVCC, or
WAL, these were major features that greatly enhanced the system's
capabilities.
Now, looking at UNDO, I just don't see it in the same league as those
other additions. Of course, you can work on whatever you want, but I
was hoping to see another major feature addition for 7.2. We know we
badly need auto-vacuum, improved replication, and point-in-time recover.
I can see UNDO improving row reuse, and making subtransactions and
pg_log compression easier, but these items do not require UNDO.
In fact, I am unsure why we would want an UNDO way of reusing rows of
aborted transactions and an autovacuum way of reusing rows from
committed transactions, expecially because aborted transactions account
for <5% of all transactions. It would be better to put work into one
mechanism that would reuse all tuples.
If UNDO came with no limitations, it may be a good option, but the need
to carry tuples until transaction commit does add an extra burden on
programmers and administrators, and I just don't see what we are getting
for it.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
