| 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 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-11-09 23:17:42 | Re: anti-join chosen even when slower than old plan |
| Previous Message | bricklen | 2010-11-09 22:59:02 | Re: Huge overestimation in rows expected results in bad plan |