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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
