On 3/23/11 2:08 PM, "Claudio Freire" <klaussfreire@xxxxxxxxx> wrote: >On Wed, Mar 23, 2011 at 6:00 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Claudio Freire <klaussfreire@xxxxxxxxx> 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@xxxxxxxxxxxxxx) >To make changes to your subscription: >http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
