Re: Fwd: Clarification about HOT
От | Pavan Deolasee |
---|---|
Тема | Re: Fwd: Clarification about HOT |
Дата | |
Msg-id | 2e78013d0711050619w35e12229x3ef651593416cfaa@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: Clarification about HOT ("Gokulakannan Somasundaram" <gokul007@gmail.com>) |
Ответы |
Re: Fwd: Clarification about HOT
|
Список | pgsql-hackers |
<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>
В списке pgsql-hackers по дате отправления: