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(at)candle(dot)pha(dot)pa(dot)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)