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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: anti-join chosen even when slower than old plan
Дата
Msg-id 4CD97FDE02000025000374D1@gw.wicourts.gov
обсуждение исходный текст
Ответ на anti-join chosen even when slower than old plan  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: anti-join chosen even when slower than old plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
"Kevin Grittner" <Kevin.Grittner@wicourts.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

В списке pgsql-performance по дате отправления:

Предыдущее
От: bricklen
Дата:
Сообщение: Re: Huge overestimation in rows expected results in bad plan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: anti-join chosen even when slower than old plan