Actually, PG's non-overwriting storage manager give exactly the same benefits as Oracle's REDO-log reading of old tuple contents, but at much lower cost. MVCC (writers don't block readers, writers only block the rows they're writing to other writers) is almost a trivial feature of PG, whereas it is complex in the overwriting storage manager scenario.
The downside is that PG suffers when tables are subjected to frequent updates and deletes - tables grow, and VACUUM ANALYZE is the result.
The PG group are working on two fronts:
1. Investigating overwriting storage manager algorithms (with the additional complexities implemented by Oracle to maintain proper row-level locking behavior)
2. Looking into what might be called hybrid techniques. PG 7.2 actually includes a first cut at a "low-cost" VACUUM command. There are a bunch of areas for exploration in this area.
I look at #1 as being a tried-and-proven approach that sacrifices much of PG's inherent simplicity. Not necessarily a bad thing, but the current simplicity is awfully attractive.
Option #2 involves creative work, which AFAIK has not been fully explored in academia or industry, so is more innovative, which means that grabbing the best of both worlds may take a relatively long time.
So the future will be interesting ...
The interesting thing is that whichever approach they take, they have a good chance of overtaking Oracle at this level. In a sense it's not fair - early RDBMS folks really had no choice but to implement overwriting storage managers, because storage was *expensive*. Now, all that one worries about with PG is whether or not the cost of a VACUUM once a night is too expensive for a 24*7 website. Disk storage for most of us is as nearly zero-cost as one can imagine (compared to my days purchasing DEC 200 MB washing machine drives for *choke* $36K. OK I never paid that, but it was list and many did).
