Re: Fwd: Clarification about HOT

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?

Actually i don't know what should be the best practice. Should i start a
discussion, take inputs from everyone and start a implementation? (Or)
Should i finish the task, get the performance figures and then come to the
forum?
I realize, that i am doing something wrong here.

HOT in its present implementation has some complexities associated, as it is
dealt as a special case. I saw that you have also made that comment in your
review. The only place where HOT is innovative is in its underlying
assumption
- Since we are not storing the snapshot info into the index, it need not get
updated, if the index info is not changing.

Currently we have implemented in a very limited sense- works only when you
do in-page updates, works only when no index get updated.
It would relish its completeness, if it works across pages and works
treating each index as a seperate entity and makes decisions on updating it
on a index-by-index basis.

By doing this, we will have a rich indexing infrastructure, where thin
indexes are suitable for heavily updated tables and thick indexes would be
suitable for heavily selected tables.

I definitely need guidance from you, before going into its implementation.
So please don't consider this as a proposal. With your experience, try to
gauge the usefulness of this feature. Some small tricks from you to make it
even more effective, would also be very useful.

Thanks,
Gokul.

On 11/5/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> writes:
> > May be i am missing something in the big picture. Please clarify me on
> that.
>
> Locking. Your proposal involves lots of multi-page operations, which
> are best avoided.
>
> Moreover, you have offered no data to suggest that there would be any
> real gain from all this extra complexity.
>
> regards, tom lane
>

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