> The other >> problem is the extra write load created by needing to update the index's >> copies of the hint bits; not to mention extra writes to freeze the xids >> when they get old enough. >> > But Tom, i remember that the vacuum was faster when index had visibility > info, since we need not touch the table. But maybe i am wrong. >
I disagree with that, Gokul -- if the ordering operators are volatile or just incorrect, during DELETE, you could set xmax in the wrong IndexTuple. Then there will be another IndexTuple that says it's visible, but it points to a non-visible heap tuple. I think you should follow the pointers to the heap before you decide to let an index tuple remain in the index during vacuum. This would ensure that all references from an index to a heap tuple are removed before vacuuming the heap tuple. I would be worried about what might break if this invariant doesn't hold. Tom is right about all the extra overhead involved with keeping visibility info in the index. But it can be a good trade-off in some cases. Karl