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