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/truncatedby 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