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
Ответ на
Re: Planner performance extremely affected by an hanging transaction (20-30 times)? (Kevin Grittner)
Список
Дерево обсуждения
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>
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 по дате отправления
От: jesper@krogh.cc
Дата: