Re: [HACKERS] proposals for LLL, part 1

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