<br /><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204);
margin:0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The other<br />
problemis the extra write load created by needing to update the index's<br /> copies of the hint bits; not to mention
extrawrites to freeze the xids<br /> when they get old enough.<br /></blockquote></div></div>But Tom, i remember that
thevacuum was faster when index had visibility info, since we need not touch the table. But maybe i am wrong. <br
/></blockquote></div><br/>I disagree with that, Gokul -- if the ordering operators are volatile or just incorrect,
duringDELETE, you could set xmax in the wrong IndexTuple. Then there will be another IndexTuple that says it's visible,
butit points to a non-visible heap tuple. I think you should follow the pointers to the heap before you decide to let
anindex tuple remain in the index during vacuum. This would ensure that all references from an index to a heap tuple
areremoved before vacuuming the heap tuple. I would be worried about what might break if this invariant doesn't
hold.<br/><br />Tom is right about all the extra overhead involved with keeping visibility info in the index. But it
canbe a good trade-off in some cases. <br /><br />Karl<br />
