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 по дате отправления: