On 11/5/07, Martijn van Oosterhout <kleptog@svana.org> wrote: On Mon, Nov 05, 2007 at 09:32:08PM +0530, Gokulakannan Somasundaram wrote:
> 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.
Ok, I've been following this tangentially, but here is one thing I
really don't understand: Sure, you might save this cost during update,
but you do incur this cost while updating the head of the chain. There
is no link from the chain to the index tuple, so the work to find the
current index tuple is nearly the same as the cost to create a new one.
It seems to me that updating and pruning the head will happen about
equally often, so I'm not sure you're saving anything here. Or am I
missing something?
Whatever you just said will happen during the index Vacuum. Instead of marking a particular tuple as Dead/ ready to be Vacuumed, we will update its tid to point to the tuple which is next to the head of the chain. This won't incur extra overhead, except that during the Vacuum process we will carry the tid of the tuple, which is next to the head of the chain(a memory overhead).
Hope , i was clear. Please get back, in case you haven't understood.
--
Thanks,
Gokul.
CertoSQL Project,
Allied Solution Group.
(
www.alliedgroups.com)
