RE: Plans for solving the VACUUM problem

> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev(at)SECTORBASE(dot)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