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

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Дата
Msg-id CAMkU=1w0kr9SLcuZYuz6t7kvMiep5RpwD5OEADaDQQTc-cyqdw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Planner performance extremely affected by an hanging transaction (20-30 times)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Tue, Sep 24, 2013 at 3:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.


Would it really be indefinite?  Would it be different from if someone inserted a wild value, committed, then deleted it and committed that?  It seems like eventually the histogram would have to get rebuilt with the ability to shrink the range.

To get really complicated, it could stop at an in-progress tuple and use its value for immediate purposes, but suppress storing it in the histogram (storing only committed, not in-progress, values).

Cheers,

Jeff

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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: Performance bug in prepared statement binding in 9.2?
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?