<br /><br /><div class="gmail_quote">On Nov 5, 2007 7:37 PM, Gokulakannan Somasundaram <<a
href="mailto:gokul007@gmail.com">gokul007@gmail.com</a>>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Tom, <br /> Let
metry to understand your statement.<br /><br />What extra multi-page operations are we doing? <br /> Currently, during
Vacuum, we goto the Index and mark it as dead and reclaim the space. For doing this, we are acquiring a Super-Exclusive
lock.After this implementation, we would update the index tuple instead of marking it for cleanup. What can be foreseen
asa locking overhead here? <br /><br /><br /></blockquote></div><br />Its not just about vacuuming. You need to worry
aboutlocking during the<br />HOT-fetches as well as chain pruning. There could be tricky corner cases<br />between
index/seqscans and pruning. And don't forget CREATE INDEX <br />which would become even more challenging if you have
HOTchains<br />spanning multiple pages.<br /><br />This is not to discourage you from trying to improve HOT. But
once-upon-a-time<br/>we had this multi-page HOT (it was called Heap-Overflow-Tuple) and I can <br />tell you: it was
reallycomplex.<br clear="all" /><br /><br />Thanks,<br />Pavan<br /><br />-- <br />Pavan Deolasee<br />EnterpriseDB
<ahref="http://www.enterprisedb.com">http://www.enterprisedb.com</a>
