Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 178D21337BEC for ; Fri, 25 Mar 2011 15:02:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 52662-01 for ; Fri, 25 Mar 2011 18:02:33 +0000 (UTC) X-Greylist: delayed 00:10:03.304046 by SQLgrey-1.7.6 Received: from EXHUB018-3.exch018.msoutlookonline.net (exhub018-3.exch018.msoutlookonline.net [64.78.17.18]) by mail.postgresql.org (Postfix) with ESMTP id 81F351337BCD for ; Fri, 25 Mar 2011 15:02:25 -0300 (ADT) Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-3.exch018.msoutlookonline.net ([64.78.17.18]) with mapi; Fri, 25 Mar 2011 10:52:21 -0700 From: Scott Carey To: Claudio Freire , Tom Lane CC: Josh Berkus , postgres performance list Date: Fri, 25 Mar 2011 10:55:08 -0700 Subject: Re: Shouldn't we have a way to avoid "risky" plans? Thread-Topic: [PERFORM] Shouldn't we have a way to avoid "risky" plans? Thread-Index: AcvrFWPQcQRxHqnkRX2ylc4wyBJDeQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201103/338 X-Sequence-Number: 43017 On 3/23/11 2:08 PM, "Claudio Freire" wrote: >On Wed, Mar 23, 2011 at 6:00 PM, Tom Lane wrote: >> Claudio Freire writes: >>> In my head, safer =3D 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)) !=3D 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. > >--=20 >Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance