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
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 |