Fwd: Fwd: Clarification about HOT

Again Forgot to include the group...

---------- Forwarded message ----------
From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
Date: Nov 5, 2007 5:09 PM
Subject: Re: [HACKERS] Fwd: Clarification about HOT
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>

On 11/5/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>
> 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.

OK. If HOT updates are going to be across pages, we may not know whether we
need to do Pruning, because we don't know whether it is a in-page HOT/
out-of page HOT. May be we can allocate some extra bits for that. I am not
favouring it. That's an option to be tried out.

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

Yes, but those arguments were centered around the current implementation,
where we have a HOT stub, which will point us to the latest live HOT Tuple.
the two problems which were put forth in this thread are
a) updating two pages concurrently and
Soln: We are just following the current Vacuum process. We are updating the
index tuple tid, instead of reclaiming its space with a Super Exclusive
lock. We will vacuum the heap tuple as usual.

b) we won't know the HOT chain stub tid, when we encounter a HOT dead tuple
Soln: Whenever we find a HOT dead tuple, during vacuum, we will add it to
the list(tid_reaped uses) with the next-in-line HOT Tuple. So when we vacuum
the index, it would be taken care of

i am actually expecting some issues, as this is not a proposal and just a
discussion

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

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