Re: Fwd: Clarification about HOT

On 11/5/07, Heikki Linnakangas <heikki(at)enterprisedb(dot)com> wrote:
>
> Gokulakannan Somasundaram wrote:
> > Thanks Heikki. To clarify, there won't be any redirect-line pointers in
> this
> > implementation. That space is saved. We will have the index tuple point
> to
> > the latest live tuple in the update chain. So no need for redirect-line
> > pointers.
>
> The redirected line pointers are there for a reason. The reason is to be
> able to retail vacuum (= prune) a page without having to do a regular
> vacuum, scanning all indexes.
>
> If you lose that ability, the idea is dead in the water.
>
> --

Since we are going to have the index point to the top of the chain and
sliding the chain happens concurrently with index and heap, there is no need
for redirected line pointers. But i doubt whether we can retail Vacuum a
page since there is just one HOT chain in the page. We can retail Vacuum
only the HOT chain and for the rest of the tuples, which are not HOT
updated, we need to consult with the indexes. Any other tuple in that page
has to go through the normal Vacuum process. Is my understanding correct
here? If so, we don't retail vacuum a page. We just try to shorten the HOT
chain at the expense of some space overhead. If this is going to give so
much benefit, then may be the design can be made slightly flexible in order
to accomodate it.
Say, if we have a table with 4 indexes and updates occur in such intervals,
we may not be able to find space in the same page for the update. Currently
we are incurring the overhead of updating all the indexes in this scenario.
Even if one of the index is updated, we will be incurring the same overhead
again in the current scenario.
In the proposed scenario, we will not have all those overheads. if we feel
that this overhead is required for achieving a pruning of HOT chain, then i
think we should let drop this idea.

Thanks,
Gokul.

Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>

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