Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Any better plan for this query?..
Дата
Msg-id 1241645035.6109.26.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Ответы Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Re: Any better plan for this query?..  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-performance
On Wed, 2009-05-06 at 10:31 +0200, Dimitri wrote:

> I've already tried a target 1000 and the only thing it changes
> comparing to the current 100 (default) is instead of 2404 rows it says
> 240 rows, but the plan remaining the same..

Try both of these things
* REINDEX on the index being used in the query, then re-EXPLAIN
* enable_hashjoin = off, then re-EXPLAIN

You should first attempt to get the same plan, then confirm it really is
faster before we worry why the optimizer hadn't picked that plan.

We already know that MySQL favors nested loop joins, so turning up a
plan that on this occasion is actually better that way is in no way
representative of general performance. Does MySQL support hash joins?

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Transparent table partitioning in future version of PG?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Transparent table partitioning in future version of PG?