On Mon, 9 Oct 2000, Bruce Momjian wrote:
> > > > Sorry, that's what I meant ... why should marking a column as 'deleted'
> > > > and running a 'vacuum' to clean up the physical table be any less
> > > > crash-safe?
> > >
> > > It is not. The only downside is 2x disk space to make new versions of
> > > the tuple.
> >
> > huh? vacuum moves/cleans up tuples, as well as compresses them, so that
> > the end result is a smaller table then what it started with, at/with very
> > little increase in the total size/space needed to perform the vacuum ...
> >
> > if we reduced vacuum such that it compressed at the field level vs tuple,
> > we could move a few tuples to the end of the table (crash safe) and then
> > move N+1 to position 1 minus that extra field. If we mark the column as
> > being deleted, then if the system crashes part way through, it should be
> > possible to continue after the system is brought up, no?
>
> If it crashes in the middle, some rows have the column removed, and some
> do not.
hrmm .. mvcc uses a timestamp, no? is there no way of using that
timestamp to determine which columns have/haven't been cleaned up
following a crash? maybe some way of marking a table as being in a 'drop
column' mode, so that when it gets brought back up again, it is scan'd for
any tuples older then that date?
