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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 24, 2013 at 3:35 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Kevin Grittner <kgrittn@xxxxxxxxx> 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

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux