Re: Searching for the cause of a bad plan

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Searching for the cause of a bad plan
Дата
Msg-id 1190372365.4202.14.camel@ebony.site
обсуждение исходный текст
Ответ на Searching for the cause of a bad plan  (Csaba Nagy <nagy@ecircle-ag.com>)
Ответы Re: Searching for the cause of a bad plan  (Csaba Nagy <nagy@ecircle-ag.com>)
Список pgsql-performance
On Fri, 2007-09-21 at 12:03 +0200, Csaba Nagy wrote:
> prepare test_001(bigint) as
> SELECT tb.*
> FROM table_a ta
> JOIN table_b2 tb ON ta.b=tb.b
> WHERE ta.a = $1
> ORDER BY ta.a, ta.b
> limit 10;

Please re-run everything on clean tables without frigging the stats. We
need to be able to trust what is happening is normal.

Plan2 sees that b1 is wider, which will require more heap blocks to be
retrieved. It also sees b1 is less correlated than b2, so again will
require more database blocks to retrieve. Try increasing
effective_cache_size.

Can you plans with/without LIMIT and with/without cursor, for both b1
and b2?

--
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


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

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Linux mis-reporting memory
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Linux mis-reporting memory