AW: Storage Manager (was postgres 7.2 features.)

> Has sufficient research been done to warrant destruction of what is
> currently there?
> 
> According to the postgres research papers, the no-overwrite storage
> manager has the following attributes...
> 
> * It's always faster than WAL in the presence of stable main memory.
> (Whether the stable caches in modern disk drives is an approximation I
> don't know).

Yes, only if you want to be able to log changes to a txlog to be able to 
rollforward changes after a restore, then that benefit is not so large any
more.

> * It's more scalable and has less logging contention. This allows
> greater scalablility in the presence of multiple processors.

Same as above, if you want a txlog you lose. 
But if we could switch the txlog off then at least in that mode
we would keep all benefits of the non-overwrite smgr.

> 
> * Instantaneous crash recovery.
> 
> * Time travel is available at no cost.

Yes. Yes, it also solves MVCC.
An overwrite smgr would need to write the old row to some temporary storage 
(Orcl: rollback segment, Ifmx: physical log) before an update.
The overwrite smgr thus needs 2 sync and one async write for one update:

1. new value to txlog (sync)
2. old value (or page) to temporary storage (rollseg) (sync)
3. new value to table (async)
(4. probably a checkpoint write)

The 7.1 implementation (non-overwrite + WAL) would only need 2 writes and no

checkpoints:
1. new value to log (sync)
2. new value to table (async)

> * Easier to code and prove correctness. (I used to work for a database
> company that implemented WAL, and it took them a large number of years
> before they supposedly corrected every bug and crash condition on
> recovery).
> 
> * Ability to keep archival records on an archival medium.

It allows the use of online native OS backups that are not synchronized with
the postmaster (e.g. a tar of your datadir). 
(Even if for practical production use we would probably need to add a
utility
for cleanup after a restore, the basic methodology is possible)

Imho that is a very large benefit.

> Is there any research on the level of what was done previously to
> warrant abandoning these benefits? Obviously WAL has its own 
> benefits, I
> just don't want to see the current benefits lost.

I do somehow agree that this step should be well considered, 
especially since WAL can work with the current non-overwrite smgr. 
It seem we can have the benefit of both, at the cost of periodic vacuums, no
?

Andreas