Re: Fwd: Clarification about HOT

>
> > 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)