Re: Yet another abort-early plan disaster on 9.3

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Yet another abort-early plan disaster on 9.3
Date: 2014-09-22 13:55:59
Message-ID: CAHyXU0xh8kFG6jiH3CLswTPiZTxJYsP==uaZP_w_FxHc0Kyqxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Sat, Sep 20, 2014 at 1:33 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> For example, we could increase the estimated cost
> for an abort-early index scan by 10X, to reflect our weak confidence in
> its correctness.

Has any progress been made on the performance farm? The problem with
suggestions like this (which seem pretty reasonable to me) is that
we've got no way of quantifying the downside. I think this is one
example of a class of plans that are high risk. Another one off the
top of my head is nestloop joins based on assumed selectivity of
multiple stacked quals. About 90% of the time, my reflective
workaround to these types of problems is to 'disable_nestloop' which
works around 90% of the time and the result are solved with monkeying
around with 'OFFSET 0' etc. In the past, a GUC controlling planner
risk has been much discussed -- maybe it's still worth considering?

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-09-22 13:58:49 Re: documentation references invalid -A assertion checks option
Previous Message Tom Lane 2014-09-22 13:54:15 Re: libpq connection status and closed fd

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2014-09-22 23:56:12 Re: Yet another abort-early plan disaster on 9.3
Previous Message Merlin Moncure 2014-09-22 13:37:50 Re: postgres 9.3 vs. 9.4