On 11/5/07, Heikki Linnakangas <heikki@enterprisedb.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)
