On 11/2/07, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 02, 2007 at 06:12:37PM +0530, Gokulakannan Somasundaram wrote: > > I am especially interested in the case of continuing the HOT chain > across > > pages. When we are actually reclaiming space, we should check the > snapshot > > and reclaim it. If it is HOT updated, we will leave the top most tuple > and > > take the rest. So then the top most tuple will remain always and any > index > > scan now has to make read two heap pages to reach the target entry.Isthis > > the only reason, it was left out? > > It's not that simple. At any point in time there may be dozens of > active snapshots, each of which might see a different tuple in the > chain. So to clear any tuple you have to wait until all active > snapshots are gone. You will almost never be able to reduce the chain > to just one.
I understand that if you have to Vacuum a tuple, it has to satisfy the necessary snapshot requirements. i will never be able to reduce the chain to just one, because the there is always a indirection at the top of HOT. I understood this. My question was is it the only reason for the decision to stop HOT across pages. As for your original question and jumping across pages, why stop at > one. Why not chain HOT tuples down 100 pages? Because then it gets very > expensive. Not to mention the locking considerations. Better keep it > simple. If you have to jump 100 pages, then you have 100 versions of the same tuple, which are not to be Vacuumed. That's a heavily updated tuple indeed. Then you will have 100 index tuples and you will anyway visit all those versions in a normal index scan. The question is whether you want to visit it through the HOT chain/ through the index entries. If you visit it through HOT chain, indexes can be in reduced size. -- Thanks, Gokul. CertoSQL Project, Allied Solution Group. (www.alliedgroups.com)
