Re: Yet another abort-early plan disaster on 9.3

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Yet another abort-early plan disaster on 9.3
Date: 2014-09-30 16:54:44
Message-ID: CAMkU=1z=LKZAxafrHgj0coAzBuwNRF1XazBbUF7Qqq9Xq3KDoQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Mon, Sep 29, 2014 at 7:12 PM, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz
> wrote:

>
> Would it be feasible to get a competent statistician to advise what data to collect, and to analyze it? Maybe it is possible to get a better estimate on how much of a table needs to be scanned, based on some fairly simple statistics. But unless research is done, it is probably impossible to determine what statistics might be useful, and how effective a better estimate could be.
>
> I have a nasty feeling that assuming a uniform distribution, may still
> end up being the best we can do - but I maybe being unduly pessimistic!.
>

As a semi-competent statistician, my gut feeling is that our best bet would
be not to rely on the competence of statisticians for too much, and instead
try to give the executor the ability to abandon a fruitless path and pick a
different plan instead. Of course this option is foreclosed once a tuple is
returned to the client (unless the ctid is also cached, so we can make sure
not to send it again on the new plan).

I think that the exponential explosion of possibilities is going to be too
great to analyze in any rigorous way.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Graeme B. Bell 2014-09-30 17:07:09 Re: Yet another abort-early plan disaster on 9.3
Previous Message Tom Lane 2014-09-30 16:32:37 Re: Yet another abort-early plan disaster on 9.3

Browse pgsql-performance by date

  From Date Subject
Next Message Graeme B. Bell 2014-09-30 17:07:09 Re: Yet another abort-early plan disaster on 9.3
Previous Message Tom Lane 2014-09-30 16:32:37 Re: Yet another abort-early plan disaster on 9.3