Re: Planner performance extremely affected by an hanging transaction (20-30 times)?

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Дата
Msg-id
5815.1380018947@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
Planner performance extremely affected by an hanging transaction (20-30 times)? Bartłomiej Romański <br@sentia.pl>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Julian <tempura@internode.on.net>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Bartłomiej Romański <br@sentia.pl>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Jeff Janes <jeff.janes@gmail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Kevin Grittner <kgrittn@ymail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Tom Lane <tgl@sss.pgh.pa.us>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Jeff Janes <jeff.janes@gmail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? jesper@krogh.cc
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? didier <did447@gmail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Jeff Janes <jeff.janes@gmail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Bartłomiej Romański <br@sentia.pl>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? didier <did447@gmail.com>
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? Jesper Krogh <jesper@krogh.cc>
Kevin Grittner  writes:
> Are we talking about the probe for the end (or beginning) of an
> index?  If so, should we even care about visibility of the row
> related to the most extreme index entry?  Should we even go to the
> heap during the plan phase?

Consider the case where some transaction inserted a wildly out-of-range
value, then rolled back.  If we don't check validity of the heap row,
we'd be using that silly endpoint value for planning purposes ---
indefinitely.  That's not an improvement over the situation that the
probe is meant to fix.

			regards, tom lane

В списке pgsql-performance по дате отправления
От: Sam Wong
Дата:
От: jesper@krogh.cc
Дата:
FAQ