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
Ответ на
Список
Дерево обсуждения
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)? 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>
On Tue, Sep 24, 2013 at 3:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kevin Grittner <kgrittn@ymail.com> writes:Consider the case where some transaction inserted a wildly out-of-range
> 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?
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
Дата:
