Heikki Linnakangas wrote:
> HEAD HOT HOT-opt HOT-pruned
> seqscan 19.9 21.1 20.1 11.5
> idxscan 27.8 31.4 30.4 13.7
>
> Explanations of the columns:
>
> HEAD: CVS HEAD
> HOT-pruned: CVS HEAD + HOT patch v15
> HOT: CVS HEAD + HOT patch v15, but with heap_page_prune_defrag short
> circuited to do nothing
> HOT-opt: CVS HEAD + HOT patch v15, but with static XidInMVCCSnapshot
> like in CVS HEAD
>
> I didn't expect a difference in seqscan performance between HEAD and
> HOT. I oprofiled it, and figured out that it's because HOT patch removed
> the static-qualifier XidInMVCCSnapshot, because it's needed in
> plancat.c. I changed it back to static, dummying out the call in
> plancat.c, and the results are now closer to each other (HOT-opt column).
>
> Comparing the idxscan columns, it looks like following the chain *is*
> more expensive than having to go through killed index pointers. Pruning
> clearly does help.
>
> Given that this test is pretty much the worst case scenario, I'm ok with
> not pruning for the purpose of keeping chains short.
Wow, that is very helpful. You have shown that pruning a single chain
is indeed a valuable operation. 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.
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.)
--
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. +