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

On Tue, Sep 24, 2013 at 3:35 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.

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