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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com