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)