From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fwd: Clarification about HOT |
Date: | 2007-11-05 16:48:04 |
Message-ID: | 20071105164804.GA17512@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | Postg토토 사이트 추천SQL |
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?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy
From | Date | Subject | |
---|---|---|---|
Next Message | Gokulakannan Somasundaram | 2007-11-05 16:58:20 | Re: Fwd: Clarification about HOT |
Previous Message | Gregory Stark | 2007-11-05 16:22:53 | Re: pgsql: Add a note about another issue that needs to be considered before |