Re: Index usage with sub select or inner joins

Поиск
Список
Период
Сортировка
От Joshua Tolley
Тема Re: Index usage with sub select or inner joins
Дата
Msg-id 20081112135405.GD22032@polonium.part.net
обсуждение исходный текст
Ответ на Index usage with sub select or inner joins  ("Julien Theulier" <julien@squidsolutions.com>)
Ответы Re: Index usage with sub select or outer joins  ("Julien Theulier" <julien@squidsolutions.com>)
Список pgsql-performance
On Wed, Nov 12, 2008 at 02:22:47PM +0100, Julien Theulier wrote:
> QUESTION: Why the planner choose seq scan in the first case & indexes scan
> in the second case? In a more general way, I observed that the planner has
> difficulties to select index scans & does in almost all the cases seq scan,
> when doing join queries. After investigations, it looks like when you join
> table a with table b on a column x and y and you have an index on column x
> only, the planner is not able to choose the index scan. You have to build
> the index corresponding exactly to the join statement btw the 2 tables

Short, general answer: index scans aren't always faster than sequential
scans, and the planner is smart enough to know that. Googling "Why isn't
postgresql using my index" provides more detailed results, but in short,
if it scans an index, it has to read pages from the index, and for all
the tuples it finds in the index, it has to read once again from the
heap, whereas a sequential scan requires reading once from the heap. If
your query will visit most of the rows of the table, pgsql will choose a
sequential scan over an index scan.

- Josh / eggyknap

Вложения

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

Предыдущее
От: "Julien Theulier"
Дата:
Сообщение: Index usage with sub select or inner joins
Следующее
От: "Julien Theulier"
Дата:
Сообщение: Re: Index usage with sub select or outer joins