> > * 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.

I'm going to implement rollback as well... Without compensation records...

> > * 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.

WAL allows "batch commit" (log commit record, then sleep for ~1/200 sec,
now write/fsync log... if no one else didn't fsync-ed it already...)

> > * Time travel is available at no cost.
> 
> Yes. Yes, it also solves MVCC.

Not with 1sec time grain...
But 6+6 bytes per tuple would be enough.

Vadim

Tue, 11 Jul 2000 12:06:35 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Storage Manager (was postgres 7.2 features.)