On Fri, 2007-02-09 at 18:10 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > > Removing the root tuple will require a VACUUM *FULL*.
> >
> > That seems unacceptable ... it won't take too long for your table to
> > fill up with stubs, and we don't want to return to the bad old days
> > when periodic VACUUM FULL was unavoidable.
> >
> > ISTM we could fix that by extending the index VACUUM interface to
> > include two concepts: aside from "remove these TIDs when you find them",
> > there could be "replace these TIDs with those TIDs when you find them".
> > This would allow pointer-swinging to one of the child tuples, after
> > which the old root could be removed. This has got the same atomicity
> > problem as for CREATE INDEX, because it's the same thing: you're
> > de-HOT-ifying the child. So if you can solve the former, I think you
> > can make this work too.
>
> I need clarification here. Is removing dead heap tuple always going to
> require an index scan, or was this just for chilling a row (adding an
> index)?
We can remove a tupled marked HEAP_ONLY_TUPLE when it is status
HEAPTUPLE_DEAD. The HEAP_UPDATE_ROOT tuple can be reduced to a
TupleStub, but not removed. Multiple tuples in the chain can be removed,
though the HEAP_UPDATE_ROOT's t_ctid must be modified to point to the
first non-removed tuple in the chain. All of that can be done when we
hold a CleanupLock on the block, without reference to the indexes; this
can be performed on-demand, when we attempt an UPDATE. This is similar
to what already happens prior to a btree split operation. (This could
also be performed by bgwriter, but that isn't proposed at this time
because the buffer transit time through the cache is often not long
enough to allow tuples to die and get benefit from space reuse).
TupleStubs can be marked for removal by a pointer-swing operation during
normal VACUUM, i.e. it will require touching the indexes.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com