Fwd: Fwd: Clarification about HOT - Mailing list pgsql-hackers
| From | Gokulakannan Somasundaram |
|---|---|
| Subject | Fwd: Fwd: Clarification about HOT |
| Date | |
| Msg-id | 9362e74e0711050347h5fef5ca2r8eee37e5aa58aed9@mail.gmail.com Whole thread Raw |
| In response to | Clarification about HOT ("Gokulakannan Somasundaram" <gokul007@gmail.com>) |
| List | pgsql-hackers |
Again Forgot to include the group...
---------- Forwarded message ----------
From: Gokulakannan Somasundaram <gokul007@gmail.com >
Date: Nov 5, 2007 5:09 PM
Subject: Re: [HACKERS] Fwd: Clarification about HOT
To: Heikki Linnakangas <heikki@enterprisedb.com>
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
( www.alliedgroups.com)
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)
---------- Forwarded message ----------
From: Gokulakannan Somasundaram <gokul007@gmail.com >
Date: Nov 5, 2007 5:09 PM
Subject: Re: [HACKERS] Fwd: Clarification about HOT
To: Heikki Linnakangas <heikki@enterprisedb.com>
On 11/5/07, Heikki Linnakangas < heikki@enterprisedb.com> wrote:
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.
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
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)
pgsql-hackers by date: