Re: Planner incorrectly choosing seq scan over index scan
| От | Meetesh Karia |
|---|---|
| Тема | Re: Planner incorrectly choosing seq scan over index scan |
| Дата | |
| Msg-id | fc5b04ca0508011630e745176@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Planner incorrectly choosing seq scan over index scan (Tobias Brox <tobias@nordicbet.com>) |
| Список | pgsql-performance |
Are you referring to the statistics gathering target for ANALYZE? Based on your email, I just tried the following and then re-ran the explain analyze but got the same "incorrect" plan:
alter table candidates617004
alter column sourceId set statistics 1000,
alter column targetId set statistics 1000;
analyze candidates617004;
alter table lte_user
alter column user_id set statistics 1000;
analyze lte_user;
Thanks for your suggestion,
Meetesh
alter table candidates617004
alter column sourceId set statistics 1000,
alter column targetId set statistics 1000;
analyze candidates617004;
alter table lte_user
alter column user_id set statistics 1000;
analyze lte_user;
Thanks for your suggestion,
Meetesh
On 8/2/05, Tobias Brox <tobias@nordicbet.com> wrote:
[Meetesh Karia - Tue at 12:19:27AM +0200]
> We're using 8.0.3 and we're seeing a problem where the planner is choosing a
> seq scan and hash join over an index scan. If I set enable_hashjoin to off,
> then I get the plan I'm expecting and the query runs a lot faster. I've also
> tried lowering the random page cost (even to 1) but the planner still
> chooses to use the hash join.
Have you tried increasing the statistics collection?
--
Tobias Brox, +47-91700050
Nordicbet, IT dept
В списке pgsql-performance по дате отправления: