> b) Whenever we Vacuum the index, we take a list of tids and check whether
> there are any index tuples pointing to it. If the Vacuumed tuple is a start
> of the HOT chain, then we will carry the next in-line HOT tuple when we goto
> Vacuum the index. If the next in-line also satisfies the Vacuum, it will
> carry with it the next in-line HOT tuple-id.
Sorry, I didn't understand that. But the way you described it earlier,
it's exactly the same thing as the pointer-swinging we talked about in
spring. Is it the same or not?
The onle extra overhead is that we will need more memory during Vacuum. We are currently calling the tid_reaped function / lazy_tid_reaped function. It does a binary search to check whether the tid pointed by the index, is present in its array/list. If it is present, it means that it is ready for Vacuum. For HOT tuples, this list will carry a replacement tid(the next in-line HOT Tuple). So instead of removing the index tuples, we will update the tid part of the index tuples. So there is no HOT stub here. The index will try to point to the live HOT tuple (it would also be the head of the chain).
Say index was previously pointing to (3,4). After (3,4) gets ready to Vacuum, it will send a replacement tid, the one in its t_data. say (5,6).
So once the Vacuum identifies the correct Index Tuple, it will update the tid portion of index tuple to (5,6). Please advise me on whether i am missing something / not clear in the explanation.
I think i am very poor in understanding things at the first time and also very poor in putting across my point the very first time. Please bear with that :)
> This will remove the in-page pruning exercises, but as i said already the
> cost of updates will go down a lot with normal indexes.
We don't want to get rid of the in-page pruning. It allows us to reclaim
dead space without having to VACUUM. That's a major point of HOT.
But we are going to get the index sizes very small and also we are going to reduce the cost of updates. Isn't that sufficient enough reason for us?
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(
www.alliedgroups.com)
