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