Re: Sequential scan on FK join

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Sequential scan on FK join
Дата
Msg-id 4353E342.2060708@archonet.com
обсуждение исходный текст
Ответ на Re: Sequential scan on FK join  (Martin Nickel <martin@portant.com>)
Список pgsql-performance
Martin Nickel wrote:
> Subject:      Re: Sequential scan on FK join
> From:         Martin Nickel <martin@portant.com>
> Newsgroups:   pgsql.performance
> Date:         Wed, 12 Oct 2005 15:53:35 -0500
>
> Richard, here's the EXPLAIN ANALYZE.  I see your point re: the 2.7M
> expected vs the 2 actual, but I've run ANALYZE on the lead table and it
> hasn't changed the plan.  Suggestions?
>
> Hash Join  (cost=62.13..2001702.55 rows=2711552 width=20)
> (actual time=40.659..244709.315 rows=2 125270 loops=1)
                                        ^^^
Hmm - is that not just a formatting gap there? Is it not 2,125,270 rows
matching which would suggest PG is getting it more right than wrong.

Try issuing "SET enable_seqscan=false" before running the explain
analyse - that will force the planner to use any indexes it can find and
should show us whether the index would help.
--
   Richard Huxton
   Archonet Ltd

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

Предыдущее
От: "Craig A. James"
Дата:
Сообщение: tsearch2/GIST performance factors?
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: tsearch2/GIST performance factors?