Ühel kenal päeval, R, 2007-02-09 kell 13:39, kirjutas Heikki
Linnakangas:
> Tom Lane wrote:
> > 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.
>
> Implementing the "replace these TIDs" operation atomically would be
> simple, except for the new bitmap index am. It should be possible there
> as well, but if the old and new tid happen to be on a different bitmap
> page, it requires some care to avoid deadlocks.
>
> Also, we'd need more work mem for vacuum.
Why do we need to muck around with indexes at all ?
What are the problems with just shuffling the last (and only visible)
tuple to replace the HOT-hain root and be done with it ?
Can there be some problems with seqscans moving one tuple at a time or
doing revisits of the "same" (by TID) tuple ? If there are can't these
be fixed by creative use of ctid chains form the original live one to
the new live one ?
> > This has got the same atomicity
> > problem as for CREATE INDEX, because it's the same thing: you're
> > de-HOT-ifying the child.
>
> Not exactly. De-HOT-ifying, or chilling, a child means inserting new
> index entries.
If we can just move the tuple inside the page we can avoid even that.
> But if we're just replacing the tids from the existing
> index entries, it's ok if we crash after replacing some but not all of
> them. The next vacuum would replace the rest of the pointers, and remove
> the old root tuple.
>
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
