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  <[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 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to