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

From Jeff Janes
Subject Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date
Msg-id CAMkU=1w0kr9SLcuZYuz6t7kvMiep5RpwD5OEADaDQQTc-cyqdw@mail.gmail.com
Whole thread Raw
In response to Re: Planner performance extremely affected by an hanging transaction (20-30 times)?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Tue, Sep 24, 2013 at 3:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.


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

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Performance bug in prepared statement binding in 9.2?
Next
From: Jeff Janes
Date:
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?