Stan Brown wrote:
>
> >
> >First, PostgreSQL is multi-version system due to its
> >non-overwriting storage manager. And so, first proposal is use
> >this feature (multi-versioning) in LLL implementation.
> >
>
> I must ask one basic question here. Since we dleted tme travel, and the
> non-overwriting storage manager is no longer required, should we at
> least discuss changing that, either as a part of the LLC work, or prior
> to it.
>
> I think one of the primary reasons to do so would be to eliminate
> vacumm. Would this not be better for a system that needs to be up
> 24x7x365?
Yes, this is very important question...
In original postgres there was dedicated vacuum process...
Vacuuming without human administration is possible but
in any case commit in non-overwriting system requires
~2 data block writes (first - to write changes, second - to
write updated xmin/xmax statuses). In WAL systems only
1 data block write required...
Ok, we have to decide two issues about what would we like
to use in future:
1. type of storage manager/transaction system -
WAL or non-overwriting.
2. type of concurrency/consistency control -
Locking or multi-versions.
These are quite different issues!
Oracle is WAL and multi-version system!
We could implement multi-version control now and switch
to WAL latter...
If we decide that locking is ok for concurrency/consistency
then it's better to switch to WAL before implementing LLL.
I personally very like multi-versions...
Comments/votes..?
Vadim
P.S. I'll be off-line up to the monday...