Skip site navigation (1) Skip section navigation (2)

Re: anti-join chosen even when slower than old plan

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-performance(at)postgresql(dot)org>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Subject: Re: anti-join chosen even when slower than old plan
Date: 2010-11-09 23:07:42
Message-ID: 4CD97FDE02000025000374D1@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-performance
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
 
> samples  %        symbol name
> 2320174  33.7617  index_getnext
 
I couldn't resist seeing where the time went within this function.
Over 13.7% of the opannotate run time was on this bit of code:

  /*
   * The xmin should match the previous xmax value, else chain is
   * broken.  (Note: this test is not optional because it protects
   * us against the case where the prior chain member's xmax aborted
   * since we looked at it.)
   */
  if (TransactionIdIsValid(scan->xs_prev_xmax) &&
      !TransactionIdEquals(scan->xs_prev_xmax,
                        HeapTupleHeaderGetXmin(heapTuple->t_data)))
      break;
 
I can't see why it would be such a hotspot, but it is.
 
-Kevin

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-11-09 23:17:42
Subject: Re: anti-join chosen even when slower than old plan
Previous:From: bricklenDate: 2010-11-09 22:59:02
Subject: Re: Huge overestimation in rows expected results in bad plan

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group