Re: Fwd: Clarification about HOT

Gokulakannan Somasundaram wrote:
>>> 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.

To answer the question I asked you, based on the above, this really is 
exactly the same pointer-swinging we talked about in spring.

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

No.

You haven't actually explained why you'd have to "remove the in-page 
pruning exercises". I suspect that's not true.

Not that any of this really matters, until you address the arguments 
against doing HOT updates across pages in the first place.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com