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)?
Дата
Msg-id e8795f5e292a0bd1a4d8ebbcb54e4a98.squirrel@shrek.krogh.cc
обсуждение исходный текст
Ответ на 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)?
Список pgsql-performance
> Kevin Grittner <kgrittn@ymail.com> 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.

Apparently it is waiting for locks, cant the check be make in a
"non-blocking" way, so if it ends up waiting for a lock then it just
assumes non-visible and moves onto the next non-blocking?

This stuff is a 9.2 feature right? What was the original problem to be
adressed?

--
Jesper



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?