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

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Shouldn't we have a way to avoid "risky" plans?
Дата
Msg-id 43B628C5-9CE2-4C58-999F-30BCAE6BC5C8@nasby.net
обсуждение исходный текст
Ответ на Re: Shouldn't we have a way to avoid "risky" plans?  (Claudio Freire <klaussfreire@gmail.com>)
Список pgsql-performance
On Mar 24, 2011, at 5:23 PM, Claudio Freire wrote:
> I routinely have to work around query inefficiencies because GEQO does
> something odd - and since postgres gives me too few tools to tweak
> plans (increase statistics, use subqueries, rephrase joins, no direct
> tool before CTEs which are rather new), it becomes an art form, and it
> becomes very unpredictable and an administrative burden. Out of the
> blue, statistics change, queries that worked fine start to perform
> poorly, and sites go down.
>
> If GEQO could detect unsafe plans and work around them automatically,
> it would be a major improvement.

This isn't limited to GEQO queries either. Every few months we'll have what should be a very fast query suddenly become
farslower. Still on the order of seconds, but when you're running several of those a second and they normally take
fractionsof a second, this kind of performance degradation can easily bring a server to it's knees. Every time this has
happenedthe solution has been to re-analyze a fairly large table; even with default stats target of 1000 it's very easy
forone bad analyze to ruin your day.  
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



В списке pgsql-performance по дате отправления:

Предыдущее
От: Denis de Bernardy
Дата:
Сообщение: Re: row estimate very wrong for array type
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Postgres 9.0.4 + Hot Standby + FusionIO Drive + Performance => Query failed ERROR: catalog is missing 1 attribute(s) for relid 172226