Re: Shouldn't we have a way to avoid "risky" plans?

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Shouldn't we have a way to avoid "risky" plans?
Date: 2011-03-25 17:55:08
Message-ID: C9B21E17.2D11C%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 3/23/11 2:08 PM, "Claudio Freire" <klaussfreire(at)gmail(dot)com> wrote:

>On Wed, Mar 23, 2011 at 6:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
>>> In my head, safer = better worst-case performance.
>>
>> If the planner starts operating on the basis of worst case rather than
>> expected-case performance, the complaints will be far more numerous than
>> they are today.
>
>I imagine, that's why, if you put my comment in context, I was talking
>about picking a safer plan only when the "better on average one" fails
>miserably.

Postgres' assumption about what is 'better on average' is wrong in the
presence of nonlinear relationships between various statistics and
execution time anyway.

AVG(f(x)) != f(AVG(x))

In english, the fastest plan for the average (most likely) case is not
always the fastest plan on average. It works very well for many cases,
but falls down in others.

Many of the 'why is this query slow' and 'I wish there were hints'
problems I see here that are not user error seem related to this. The
approaches discussed by Nathan Boley and Claudio Freire in this thread
could significantly mitigate many of the issues I have seen when wrestling
with the planner.

>
>--
>Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Nathan Boley 2011-03-25 22:43:04 Re: Shouldn't we have a way to avoid "risky" plans?
Previous Message Mahadevan, Mridula 2011-03-25 17:32:42 Re: Analyze on temp table taking very long