Re: Yet another abort-early plan disaster on 9.3 - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Yet another abort-early plan disaster on 9.3
Date
Msg-id CAHyXU0wFAKiwgybbEAX=597-MxtPGdf0bmQvRSJq9db1KTZ6nA@mail.gmail.com
Whole thread Raw
In response to Re: Yet another abort-early plan disaster on 9.3  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Yet another abort-early plan disaster on 9.3
Re: Yet another abort-early plan disaster on 9.3
List pgsql-performance
On Fri, Sep 26, 2014 at 3:06 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The problem, as I see it, is different. We assume that if there are
> 100 distinct values and you use LIMIT 1 that you would only need to
> scan 1% of rows. We assume that the data is arranged in the table in a
> very homogenous layout. When data is not, and it seldom is, we get
> problems.

Hm, good point -- 'data proximity'.  At least in theory, can't this be
measured and quantified?  For example, given a number of distinct
values, you could estimate the % of pages read (or maybe non
sequential seeks relative to the number of pages) you'd need to read
all instances of a particular value in the average (or perhaps the
worst) case.   One way of trying to calculate that would be to look at
proximity of values in sampled pages (and maybe a penalty assigned for
high update activity relative to table size).  Data proximity would
then become a cost coefficient to the benefits of LIMIT.

merlin


pgsql-performance by date:

Previous
From: Matúš Svrček
Date:
Subject: Re: after upgrade 8.4->9.3 query is slow not using index scan
Next
From: "Graeme B. Bell"
Date:
Subject: Re: Very slow postgreSQL 9.3.4 query