Re: Fwd: Clarification about HOT
| От | Gokulakannan Somasundaram |
|---|---|
| Тема | Re: Fwd: Clarification about HOT |
| Дата | |
| Msg-id | 9362e74e0711050634x21ec3adajc81028fa88f97b0@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Fwd: Clarification about HOT ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
| Ответы |
Re: Fwd: Clarification about HOT
("Pavan Deolasee" <pavan.deolasee@gmail.com>)
|
| Список | pgsql-hackers |
Thanks for the feedback. Let me try to put what is there in my mind for this. Please clarify whether my assumptions are valid
In the mean-while, if you can think of a specific case, in which this design would fail, please notify me.
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)
On 11/5/07, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
During HOT fetches, the normal case is that we will take the tuple-id from the index, goto the top of HOT chain, descend from there, until we reach the right tuple. So this would involve BUFFER_SHARE locks which should not be of any concern. There may not be anything called chain-pruning. Instead the tuples, which are to be vacuumed, will get vacuumed, after redirecting their index tuple peers, during the Vacuum process.
In seq-scans, i think we need not worry about the HOT implementation. we need to take each tuple, check for the visibility criteria and take the appropriate step. During clean-up, we will be taking the super exclusive lock here. In Index scans, we will change the index-entry, only after obtaining the Super-Exclusive locks - so no pins - so no index scans are going on during this time
Create index has to do seq scan. so it will consider only tuples which are live at the time of creation of index. It won't worry about the HOT chains.
Thanks a lot for the encouraging words. I would definitely refer to the Heap Overflow Tuple and check, whether there are any problems that are going to recur in this.
On Nov 5, 2007 7:37 PM, Gokulakannan Somasundaram <gokul007@gmail.com > wrote:Tom,
Let me try to understand your statement.
What extra multi-page operations are we doing?
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?
Its not just about vacuuming. You need to worry about locking during the
HOT-fetches as well as chain pruning.
During HOT fetches, the normal case is that we will take the tuple-id from the index, goto the top of HOT chain, descend from there, until we reach the right tuple. So this would involve BUFFER_SHARE locks which should not be of any concern. There may not be anything called chain-pruning. Instead the tuples, which are to be vacuumed, will get vacuumed, after redirecting their index tuple peers, during the Vacuum process.
There could be tricky corner cases
between index/seq scans and pruning.
In seq-scans, i think we need not worry about the HOT implementation. we need to take each tuple, check for the visibility criteria and take the appropriate step. During clean-up, we will be taking the super exclusive lock here. In Index scans, we will change the index-entry, only after obtaining the Super-Exclusive locks - so no pins - so no index scans are going on during this time
And don't forget CREATE INDEX
which would become even more challenging if you have HOT chains
spanning multiple pages.
Create index has to do seq scan. so it will consider only tuples which are live at the time of creation of index. It won't worry about the HOT chains.
This is not to discourage you from trying to improve HOT. But once-upon-a-time
we had this multi-page HOT (it was called Heap-Overflow-Tuple) and I can
tell you: it was really complex.
Thanks a lot for the encouraging words. I would definitely refer to the Heap Overflow Tuple and check, whether there are any problems that are going to recur in this.
In the mean-while, if you can think of a specific case, in which this design would fail, please notify me.
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(www.alliedgroups.com)
В списке pgsql-hackers по дате отправления: