Re: Duplicating transaction information in indexes and performing in memory vacuum

Shridhar Daithankar <shridhar_daithankar(at)myrealbox(dot)com> writes:
> What are (more) reasons for not adding transaction information to
> index tuple, in addition to heap tuple?

> Cons are bloated indexes. The index tuple size will be close to 30
> bytes minimum.

And extra time to perform an update or delete, and extra time for
readers of the index to process and perhaps update the extra copies
of the row's state. And atomicity concerns, since you can't possibly
update the row and all its index entries simultaneously. I'm not
certain that the latter issue is insoluble, but it surely is a big risk.

> On pro* side of this, no more vacuum required (at least for part of
> data that is being used. If data isn't used, it does not need vacuum
> anyway) and space bloat is stopped right in memory, without incurring
> overhead of additional IO vacuum demands.

I do not believe either of those claims. For starters, if you don't
remove a row's index entries when the row itself is removed, won't that
make index bloat a lot worse? When exactly *will* you remove the index
entries ... and won't that process look a lot like VACUUM?

regards, tom lane