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

Fri, 17 Jul 1998 13:00:10 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] proposals for LLL, part 1
> 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.

Can you explain WAL.  I understand locking vs. multi-version.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Fri, 17 Jul 1998 01:15:37 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] proposals for LLL, part 1
Bruce Momjian wrote:
> 
> >
> > 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.
> 
> Can you explain WAL.  I understand locking vs. multi-version.

Write Ahead Log - log of changes. 

Vadim

Mon, 20 Jul 1998 11:26:40 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] proposals for LLL, part 1
> 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...

Doesn't a WAL have do an update by writing the old row to a log, then
write the changes to the real table?  It is only inserts that have only
one write?

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

If we could just get superceeded row reuse without vacuum, we can stick
with non-overwriting, can't we?

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

OK, now I have to ask what multi-version is.

I have to read that Gray book.  Did you get my e-mail on it?

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Tue, 21 Jul 1998 11:10:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] proposals for LLL, part 1
Bruce Momjian wrote:
> 
> > 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...
> 
> Doesn't a WAL have do an update by writing the old row to a log, then
> write the changes to the real table?  It is only inserts that have only
> one write?

I was wrong: WAL systems need in 2 writes (data block and log block)
and we need in 3 writes (data block, log block and data block
with updated xact statuses). But in commit time WAL have to
fsync only log (Oracle places new data there and keep old
data in rollback segments) and we have to fsync 2 files.

> 
> >
> > 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.
> 
> If we could just get superceeded row reuse without vacuum, we can stick
> with non-overwriting, can't we?

I hope...

> >
> > I personally very like multi-versions...
> 
> OK, now I have to ask what multi-version is.

This is our ability to return snapshot of data committed
in some point in time. Note, that we are able to return
different snapshots to different backends, simultaneously.

> 
> I have to read that Gray book.  Did you get my e-mail on it?

Thanks and sorry... Yes, this could help me. Do you have my 
mail address ?

Vadim

Wed, 22 Jul 1998 00:33:22 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] proposals for LLL, part 1
On Fri, Jul 17, 1998 at 01:00:10PM +0800, Vadim Mikheev wrote:
> 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...

Then the arguments are clearly in favor of WAL.

> Oracle is WAL and multi-version system!

While Oracle has some faults (or more) I agree with that choice. 

> We could implement multi-version control now and switch
> to WAL latter...

Once again I fully agree.

> I personally very like multi-versions...

Me too.

Michael
-- 
Dr. Michael Meskes		meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire!	Use Debian GNU/Linux! 

Mon, 27 Jul 1998 16:54:07 +0200
"Dr. Michael Meskes" <meskes@online-club.de>
Re: [HACKERS] proposals for LLL, part 1