Heikki Linnakangas wrote: > Bruce Momjian wrote: > > My guess is that once you prune a tuple > > you no longer have to check its visibility, and that is where the win is > > coming from. > > Yes, I think that's right. > > Oh, one more thing occured to me. Without HOT, we not only mark index > tuples pointing to dead tuples as killed, we remove them altogether if > the index page gets full. If you modify the test case so that after > doing the updates, you insert a bunch of tuples with a different key to > fill the index page, you should see CVS HEAD winning HOT without pruning > hands down. > > > If we check a tuple in a chain and the tuple is dead is it possible the > > pruning operation is cheaper than having to check the tuple again for > > visibility the next time we see it? If so, we can just always prune > > when we see a dead tuple in the chain, which I believe was the original > > design. Pruning becomes an operation similar to marking an index entry > > as dead. (I assuming pruing does not generate WAL traffic.) > > Pruning does generate a WAL record at the moment. Maybe you could do > some kind of a quick pruning without a WAL record. Like just modify the > ctid of the oldest dead tuple in the chain, or the redirecting line > pointer if there is one, to point to the latest live tuple, without > removing the dead tuples or the line pointers.
I am wondering what you even mean by removing the dead tuples when pruning. I thought only defragmentation removed tuples. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
