Re: Fwd: Clarification about HOT
| От | Gokulakannan Somasundaram |
|---|---|
| Тема | Re: Fwd: Clarification about HOT |
| Дата | |
| Msg-id | 9362e74e0711050706t5c6e8544wc3c12fb2aef073f7@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fwd: Clarification about HOT (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Fwd: Clarification about HOT
(Heikki Linnakangas <heikki@enterprisedb.com>)
|
| Список | pgsql-hackers |
On 11/5/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I think, in my suggestion, there are only two steps, redirect the index tuple tid to point to a new tuple and mark the parent heap tuple vacuumed. This is no different from the existing Vacuum process, except that we are updating the index tuple, instead of marking it for Vacuum . I think you are thinking about the current implementation. We need not mark any tuple as HOT in the proposed one. Instead our code will work under the assumption that normal indexes won't get updated, unless the indexing info changes. i don't foresee a requirement for HOT classification. Please explain me, if it is required in any case.
Currently, we are maintaining a list/array in the tid_reaped or lazy_tid_Reaped function. So this will contain all the tids that can be Vacuumed. In our case,as already explained, all the heap tuples, which are updated, will contain an extra tid, which is taken from it t_ctid stored in t_data. So after we update the tid in the index-tuple, we can call tid_reaped again to check whether the replaced tid has to get replaced / can be Vacuumed
If the chain ends, the heap tuple would have got marked deleted. it won't point to any tuple in the t_data and would have got marked HEAP_XMAX_VALID. So it is the same case as Vacuuming a normal tuple. Have i correctly answered your question??
i don't know, what is a re-direct line pointer. The tid part of index tuple can be made to point to any place. So i don't understand what you mean over here.
Yes, i think bitmap index scans will get affected, but only for the select on heavily updated tuples. That's the cost we need to pay for extracting the performance out of updates. As i already said the normal index would be the index for heavily updated tables and thick index would be the index for tables with heavy selects.
We can also look at optimizing the index tuple structure to reduce its footprint.
"Gokulakannan Somasundaram" <gokul007@gmail.com> writes:
> Currently, during Vacuum, we goto the Index and mark it as dead and
> reclaim the space. For doing this, we are acquiring a Super-Exclusive lock.
> After this implementation, we would update the index tuple instead of
> marking it for cleanup. What can be foreseen as a locking overhead here?
There are three operations involved: marking the child tuple not-HOT,
updating the index entry(s), and removing the parent tuple. I doubt you
can do them safely as independent atomic operations; I think you'll need
to have more than one page locked at a time.
I think, in my suggestion, there are only two steps, redirect the index tuple tid to point to a new tuple and mark the parent heap tuple vacuumed. This is no different from the existing Vacuum process, except that we are updating the index tuple, instead of marking it for Vacuum . I think you are thinking about the current implementation. We need not mark any tuple as HOT in the proposed one. Instead our code will work under the assumption that normal indexes won't get updated, unless the indexing info changes. i don't foresee a requirement for HOT classification. Please explain me, if it is required in any case.
The locking problem also
applies to trying to collapse out a dead HOT tuple that's in the middle
of the chain:
Currently, we are maintaining a list/array in the tid_reaped or lazy_tid_Reaped function. So this will contain all the tids that can be Vacuumed. In our case,as already explained, all the heap tuples, which are updated, will contain an extra tid, which is taken from it t_ctid stored in t_data. So after we update the tid in the index-tuple, we can call tid_reaped again to check whether the replaced tid has to get replaced / can be Vacuumed
if it's the end of a cross-page link then you need two
pages super-exclusive-locked in order to do that.
If the chain ends, the heap tuple would have got marked deleted. it won't point to any tuple in the t_data and would have got marked HEAP_XMAX_VALID. So it is the same case as Vacuuming a normal tuple. Have i correctly answered your question??
There's also the little problem that a redirect line pointer doesn't
have room for a cross-page link,
i don't know, what is a re-direct line pointer. The tid part of index tuple can be made to point to any place. So i don't understand what you mean over here.
and the big problem that having to
chase across multiple pages for an index lookup would almost certainly
negate any performance gains you might get. (In particular it'd
completely destroy locality of access for bitmap indexscans...)
Yes, i think bitmap index scans will get affected, but only for the select on heavily updated tuples. That's the cost we need to pay for extracting the performance out of updates. As i already said the normal index would be the index for heavily updated tables and thick index would be the index for tables with heavy selects.
We can also look at optimizing the index tuple structure to reduce its footprint.
Please get back, if i am not clear in any.
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)
В списке pgsql-hackers по дате отправления: