"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: > "Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> 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. Main-memory access waits, maybe? If at_chain_start is false, that xmin fetch would be the first actual touch of a given heap tuple, and could be expected to have to wait for a cache line to be pulled in from RAM. However, you'd have to be spending a lot of time chasing through long HOT chains before that would happen enough to make this a hotspot... regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
