Re: Fwd: Clarification about HOT - Mailing list pgsql-hackers

Tom,
       Let me try to understand your statement.

What extra multi-page operations are we doing?
  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 as a locking overhead here?

Actually i don't know what should be the best practice. Should i start a discussion, take inputs from everyone and start a implementation? (Or) Should i finish the task, get the performance figures and then come to the forum?
I realize, that i am doing something wrong here.

HOT in its present implementation has some complexities associated, as it is dealt as a special case. I saw that you have also made that comment in your review. The only place where HOT is innovative is in its underlying assumption
- Since we are not storing the snapshot info into the index, it need not get updated, if the index info is not changing.

Currently we have implemented in a very limited sense- works only when you do in-page updates, works only when no index get updated.
It would relish its completeness, if it works across pages and works treating each index as a seperate entity and makes decisions on updating it on a index-by-index basis.

By doing this, we will have a rich indexing infrastructure, where thin indexes are suitable for heavily updated tables and thick indexes would be suitable for heavily selected tables.

I definitely need guidance from you, before going into its implementation. So please don't consider this as a proposal. With your experience, try to gauge the usefulness of this feature. Some small tricks from you to make it even more effective, would also be very useful.

Thanks,
Gokul.





--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)