> Do we want to head for an overwriting storage manager?
> 
> Not sure.  
> 
> Advantages:  UPDATE has easy space reuse because usually done
> in-place, no index change on UPDATE unless key is changed.
> 
> Disadvantages:  Old records have to be stored somewhere for MVCC use. 
> Could limit transaction size.

Really? Why is it assumed that we *must* limit size of rollback segments?
We can let them grow without bounds, as we do now keeping old records in
datafiles and letting them eat all of disk space.

> UNDO disadvantages are:
> 
> 	Limit size of transactions to log storage size.

Don't be kidding - in any system transactions size is limitted
by available storage. So we should tell that more disk space
is required for UNDO. From my POV, putting $100 to buy 30Gb
disk is not big deal, keeping in mind that PGSQL requires
$ZERO to be used.

Vadim

Fri, 25 May 2001 09:37:16 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Plans for solving the VACUUM problem
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
> 
> > Do we want to head for an overwriting storage manager?
> > 
> > Not sure.  
> > 
> > Advantages:  UPDATE has easy space reuse because usually done
> > in-place, no index change on UPDATE unless key is changed.
> > 
> > Disadvantages:  Old records have to be stored somewhere for MVCC use. 
> > Could limit transaction size.
> 
> Really? Why is it assumed that we *must* limit size of rollback segments?
> We can let them grow without bounds, as we do now keeping old records in
> datafiles and letting them eat all of disk space.
> 

Is it proper/safe for a DBMS to allow the system eating all disk
space ? For example, could we expect to recover the database
even when no disk space available ?

1) even before WAL 
    Is 'deleting records and vacuum' always possible ?
    I saw the cases that indexes grow by vacuum.

2) under WAL(current)
    If DROP or VACUUM is done after a checkpoint, wouldn't
    REDO recovery add the pages drop/truncated by the 
    DROP/VACUUM ?
 
3) with rollback data
    Shouldn't WAL log UNDO operations either ?
    If so, UNDO requires an extra disk space which could
    be unlimitedly big.

There's another serious problem. Once UNDO is required
with a biiiig rollback data, it would take a veeery long time
to undo. It's quite different from the current behavior. Even
though people want to cancel the UNDO, there's no way
unfortunately(under an overwriting smgr).

regards,
Hiroshi Inoue 

Sun, 27 May 2001 17:32:54 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Plans for solving the VACUUM problem