Re: Fwd: Clarification about HOT

Thanks for the feedback. Let me try to put what is there in my mind for
this. Please clarify whether my assumptions are valid

On 11/5/07, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> wrote:
>
>
>
> On Nov 5, 2007 7:37 PM, Gokulakannan Somasundaram <gokul007(at)gmail(dot)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)