| From: | jesper(at)krogh(dot)cc |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Kevin Grittner" <kgrittn(at)ymail(dot)com>, "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>, BartÅomiej RomaÅski <br(at)sentia(dot)pl>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |
| Date: | 2013-09-24 15:01:14 |
| Message-ID: | e8795f5e292a0bd1a4d8ebbcb54e4a98.squirrel@shrek.krogh.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> Kevin Grittner <kgrittn(at)ymail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-09-24 17:43:06 | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |
| Previous Message | Tom Lane | 2013-09-24 10:35:47 | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |